I was reading an article by Rockford Lhotka about concurrency techniques that can be implemented within CSLA.NET.
With disconnected ADO recordsets, you automatically get a nice set of tools for optimistic concurrency. With ADO.NET, you can have the same thing with datasets. However, the CSLA.NET architecture doesn’t hold a dataset in the business object. This means you have to implement optimistic concurrency on your own.
Rocky suggests in the article that implementing field-level concurrency involves three sets of variables. One set keeps track of the original values. A second set keeps track of the current values edited by the user. A third set is filled with the current database values before you attempt to save the data to the database.
The example in the article implies a series of “If” statements to look for concurrency violations. My concern with this is when we add properties, we have to also add code to the concurrency checking for that field. I’d like to automate the concurrency checking.
Perhaps the concurrency checking could be automated with reflection. During the fetch process, reflection could be used to load a list of original values.
During the update process, a “current” copy of the business object could be loaded. Using reflection, the properties of the of “current” business object could be compared to the original values. The properties of the “edited” business object could also be compared to the original values. If both are different we have a concurrency violation.
This adds a lot of overhead, so performance might be a problem.