In a typical production system which is used by multiple users at the same time, we need to take into account the conflicts that arise when two users try to change the same record at the same time. These are generally handled by two types of strategies.
1. Pessimistic Concurrency
2. Optimistic concurrency.
By default LINQ will apply the Optimistic Concurrency strategy.
To repro the Concurrency problem in LINQ to SQL following the given steps.
1. Open Visual Studio 2008 and click New ->Project
2. Create a new console application
3. Add a new LINQ to SQL class to the project and name it as Northwind.dbml
4.Add the following objects from the server explorer
5. In the main method add the code as shown below
6. Put a break point at the SubmitChanges method.
7. When the breakpoint hits the method, go and update the value of the Postal code for the Alfki customer as shown below.
8. Now if you press F10 in the Visual Studio, it will throw an error as shown below.
Now the question here is how the framework knows, whether the records it is planning to update or delete has or hasn’t been changed?
Configuring classes to support optimistic concurrency in LINQ to SQL is extremely easy. In fact, by establishing the table and column mappings, we’re already set to use optimistic concurrency. When calling SubmitChanges (), the DataContext will automatically implement optimistic concurrency.
LINQ to SQL handles the optimistic concurrency by the following ways
1. Using UpdateCheck
2. Using Conflicts
3. Using Transactions
I will post these as 3 seperate articles .So watch out this space for more updates