Handling Concurrency in LINQ to SQL -Part 2

In my earlier article here I showed you how to reproduce the concurreny issues in LINQ to SQL. In this article and in the subsequent articles I will write more about how to resolve the conflicts arising out of these concurrency.

USING UpdateCheck :

When SubmitChanges is called on the DataContext, the Update statement is generated and issued to the server. If no matching record is found based on the previous values passed in the WHERE clause, the context will recognize that no records are affected as part of this statement. When no records are affected, a ChangeConflictException is thrown. Depending on the situation, the number of parameters needed to implement optimistic concurrency can cause performance issues. In those cases, we can refine our mappings to identify only the fields necessary to ensure that the values didn’t change. We can do this by setting the UpdateCheck attribute

  This attribute can have 3 below mentioned possible values  



1.      AlwaysàAlways use this column for conflict detection

2.      NeveràNever use this column for conflict detection

3.      WhenChangedàNever use this column for conflict detection

 By default, UpdateCheck is set to Always, which means that LINQ to SQL will always check this column for optimistic concurrency. As an alternative, we can set it to only check if the value changes (WhenChanged) or to never check (Never).

In addition to changing the standard optimistic concurrency by setting all fields to check always, there are a couple of other concurrency models available. The first option is to simply ignore any concurrent changes and always update the records, allowing the last update to be accepted. In that case, set UpdateCheck to Never for all properties. Unless we are very sure that concurrency is not an issue, this is not a recommended solution. In most cases, it is best to inform the user that there was a conflict and provide options to remedy the situation.

In some cases, it is fine to allow two users to make changes to different columns in the same table. For example, in wide tables, we may want to manage different sets of columns with different objects or contexts. In this case, set the UpdateCheck attribute to  WhenChanged rather than Always. This is not recommended in all cases, particularly when multiple fields contribute to a calculated total. For example, in a typical OrderDetail table, columns may appear for quantity, price, and total price. If a change was made in either the quantity or price, the total price will need to be changed. If one user changes the quantity while another changes the price, the total price would not be modified properly. This form of automatic merge concurrency management does have its place. Business demands should dictate if it is appropriate in any given situation.

With LINQ to SQL, concurrency checking can be set on a field-level basis. The framework was designed to provide the flexibility to allow for various customized implementations. The default behavior is to fully support optimistic concurrency. So far, we’ve identified how to recognize when there is a conflict. The second part of the equation is what we do with the knowledge that there was a concurrency exception. This I will post in the next article. Happy reading….

This entry was posted in LINQ. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s