Continuing with the thoughts on using Chunky web service calls, one reader reminds us that using Chunky increases the potential for concurrency issues. Data remains in the client cache for a much longer period of time. It has a higher chance of becoming stale, and not representing the value currently in your data storage.
SQL Server has a technique that addresses concurrency, and optimizes the evaluation of data, with the goal of evaluating stale data based on the premise of optimistic concurrency. That means the application will assume it has the latest data, and it relies on SQL Server to confirm that fact. If the application would overwrite data modifications from another process, SQL Server would raise an error, and the application needs to resolve the problem.
When working with disconnected applications the SQL Server RowVersion data type enhances the performance of an Update action. The way it works is quite simple. Each time a user touches a record in a table having a column based on the RowVersion data type, SQL Server modifies the value of that column. The next time a user attempts to modify that record, the value from the client for the RowVersion column is compared. If the value does not match, then the user does not have the latest version of that record, and the Update is denied.
Why does this increase performance? When updates are made, SQL Server compares the clients original values all of the columns for that row with the current version. If they do not match, then the update is denied. Comparing one column per row will clearly be much faster than comparing every column in a table.
Do you have any specific implementations for optimistic concurrency you find useful? Get into the conversation by leaving a comment.
Cheers,
Ben