LINQ to SQL and Concurrency Issues

Question

We are trying to build a High-Volume Orders Record System. There are three primary tables: 1. Orders 2. OrderDetails 3. OrderShipment

The Shipment table contains n record per order and any record shipment entry can be changed before the Customer accepts th order, after which it is frozen. (A business requirement)

Although this may not happen in real world scenarios... during our load tests, we are getting System.Data.Linq.ChangeConflictException exceptions. Wrapping up the submit inside a transacion is not helping either. Can't we force LINQ to get a lock on the row for the entire duration of the update operation?

Is there any other way to get over this?

Answer 1

If you are having genuine issues with concurrent updates on the same data, then you might consider performing the entire operation in a transaction - ie getting the data and committing it. As long as you treat the get/update/commit as a short-lived, atomic operation (ie you don't pause for user-input in the middle) it should be OK.

In particular, with a serializable isolation level, nobody can update data that you have a read lock on (ie anything you have queried). The only problem is that this might lead to deadlock scenarios if different queries are reading data in different orders. AFAIK, there is no way to get LINQ-to-SQL to issue the (UPDLOCK) hint, which is a shame.

Either a TransactionScope or a SqlTransaction would do, as long as they are set as serializable isolation (which is the default for TransactionScope).

Answer 2

you may want to look into Entity Framework which executes everything as a transaction. Here are two podcasts which can also be interesting about Entity Framework.

DNRTV - part 1 - part 2

Answer 3

For this kind of situations, ie where more than one user may want to make changes to the same record/customer/order/whatever it is better to build "locking" into the application logic rather than use database locks.

Using DB locks to solve logical locking of data is going to present you with a heap of new issues. A better solution is to have columns and/or tables where you can indicate that an order/customer/etc is being edited [by a user], until when it is locked etc. Query that table (or columns) to check if the customer/order/thing is available for editing before allowing another user to edit it.

See: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3984968&SiteID=1