none
What locking mechanisms does EF provide? RRS feed

  • Question

  • I've done a small amount of work with EF (4.2), and so far love it.  We embarking on a major re-write of an old VB6 app into .NET, probably 4.0.  We'll be using EF for the local data store (a SQL Express database), but I've written some WCF services a few years ago using ADO.NET DataSets, etc, for fetching and saving data to a backend SQL Server database.  Our application consists of saving client data to several tables.  When working with a client's data it is imperative that at most only one person have a client's data "checked out" for editing purposes.  A person may have the client's data checked out for a long time (potentially days).  Others may view the data, but only one person may edit it.  One of the WCF services I wrote follows the same pattern we used with the old VB6 app, and that is to store a record into an auxillary table, indicating who has the client's data checked out, when they checked it out, etc.  If someone else tries to open the client's data, the old VB6 will first look to see if anyone else has the client's data checked out; if someone else does, then the second person will only be able to view the data.

    So I'm wondering, does EF have some way if marking data as being checked out, or locked, so that no one else can edit that data?  If so, what are these locking mechanisms?  Can they span days in duration?


    Rod

    Friday, August 17, 2012 6:56 PM

Answers

  • EF doesn't have any locking mechanism as locking is always handled at the database (or more rarely application) level.

    The most used is likely optimistic locking (that you could have used also with VB6). Basically you have a row version column that is automatically updated whenever the row is upated. This information is included in the where clause and no row is matching it means that this row has been updated by someone else while you were using it and you can take action to reconcile those changes (the idea is that it's still worth if it rarely happens).

    Here it seems you have particular requirements as locking is usually as short as possible and it might be better to start from your needs. My first though is that it looks like a replication scenario rather than really like a locking scenario. Is this is a scenario such as "taking data with you" and updating the source at a later time ? Then it seems the replication feature could perhaps help.

    If this is just a business requirement and you are 100% sure it does fit the actual need (with possibly the possible inconvenience you may have if someone is not releasing the client data in a timely manner) you could still use the same approach with EF.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    Saturday, August 18, 2012 12:50 PM

All replies

  • EF doesn't have any locking mechanism as locking is always handled at the database (or more rarely application) level.

    The most used is likely optimistic locking (that you could have used also with VB6). Basically you have a row version column that is automatically updated whenever the row is upated. This information is included in the where clause and no row is matching it means that this row has been updated by someone else while you were using it and you can take action to reconcile those changes (the idea is that it's still worth if it rarely happens).

    Here it seems you have particular requirements as locking is usually as short as possible and it might be better to start from your needs. My first though is that it looks like a replication scenario rather than really like a locking scenario. Is this is a scenario such as "taking data with you" and updating the source at a later time ? Then it seems the replication feature could perhaps help.

    If this is just a business requirement and you are 100% sure it does fit the actual need (with possibly the possible inconvenience you may have if someone is not releasing the client data in a timely manner) you could still use the same approach with EF.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    Saturday, August 18, 2012 12:50 PM
  • You are correct, this is a business requirement.  I do remember that good, ol' VB6 had optimistic locking, but that isn't what I'm talking about.  I think we'll move ahead with the mechanism we've used for several years, which I guess could best be described as "cooperative locking", as in everyone who uses this data agrees to look at the check out table first, to see if the records are "locked".

    Rod

    Thursday, August 30, 2012 3:51 PM