We can also test concurrent updates by using the client application.
In this section, we will start two clients and update the same product from these two clients at same time. We will start one of the clients in debugging mode, so we can control the execution time of the update. We will create a conflict between the updates from these two clients so we can test if this conflict is properly handled by LINQ to SQL.
The test sequence will be like this:
- First client starts.
- Second client starts.
- First client reads the product information.
- Second client reads the same product information.
- Second client updates the product successfully.
- First client tries to update the product, and fails.
The last step is where the conflict occurs, as the product has been updated in between the read and the update by the first client.
Thee steps are described in detail below:
- Start the host application in non-debugging mode.
- Set a breakpoint on the following line in the
MainForm.csfile, within theupdateButton_Clickmethod (line 77):product.UnitPrice += 1;
- Start the client application in debugging mode by pressing F5. We will refer to this client as the first client.
- In this first client application, enter 10 in the top Product ID text box, and click the Execute button to get the product's details. Note that the unit price is 32.0000.
- Now, still in this client application, enter 10 in the bottom Product ID text box, and click the Update Price button. The program should stop at the breakpoint we set earlier, and should be waiting for us to press F5 to continue.
- From the Windows Explorer, go to the LINQNorthwindClient directory:
D:SOAwithWCFandLINQProjectsLINQNorthwindMyWCF.LINQNorthwindTestsMyWCF.LINQNorthwind.ClientinDebug
- Double-click on the following client executable file to start another client. We will refer to this client as the second client:
MyWCF.LINQNorthwind.Client.exe - In the second client application, enter 10 in the bottom Product ID text box, and click the Update Price button.
- The second client update is committed to the database, and the Update Result value should be True. The price of this product has now been increased by 1 in the database, and the LastUpdateVersion should also have been updated to a new value.
- In the second client, enter 10 in the top Product ID text box, and click the Execute button to get product details. Note that the unit price is now 33.0000.
- Go to Visual Studio 2008, and press F5 to let the first client application continue. This client will first update the product, and then try to commit the update back to the database.
- The first client update fails with an error message could not update product. Error message: Row not found or changed.
- In the second client, click Execute again to get the product's details. You will see that the unit price is still 33.0000, which means that the first client's update didn't get committed to the database.
The following image is for the second client. You can see the Update Result is True, and the price after the update is 33.0000.
The following image is for the first client. You can see that the price before the update is 32.0000, and the update fails with an error message.
From the test above, we know that the concurrent update is controlled by LINQ to SQL. An optimistic locking mechanism is enforced, and one client's update won't overwrite another client's update. The client that has a conflict will be notified by a fault message.
Concurrent update locking is applied at the record level in the database. If two clients try to update different records in the database, they will not interfere with each other. For example, if you repeat the above steps to update product 10 in one client and 11 in another client, there will be no problem at all.