This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I've been working on handling optimistic concurrency issues with LS. In my simple implmentation I wrap the UOF commit to catch the OC exception. Then I start a new UOF to load all modified, deleted objects to compare for changes. Then present the user with conflict resolution options. All is fine, until I try to resave the orginal UOF. After reviewing the ObjectUnloader source it seems that the EntityState and version fields are bumped before the actual commit is finished. So what happens if an OC occurs midway through an update is you have some objects ES set to default while others are still modified, same for version info. Also, using the new UOF is not an option due to all the databinding occuring with the original classes. What I also noticed is you guys have a mechanism to queue post commit actions in the UOF and that the ObjectUnloader actual uses it for caching purposes. Why not do the same for EntityState modifications and version changing? All they need is to be wraped in delegates and queued. It would also be great if the Unloader ran through all the updates before throwing the OC exception. In that way if you have more than one OC the conflict resolution mechanism could tell the user a more accurate story. Of course, OptimisticConcurrencyException would need to list what entities were effected and so forth. Let me know what your thoughts and any downsides to this might be. Thanks again, Kavan |
|
|
|
|
Hi Kavan, Are conflicts common in your application? If so, it may be more appropriate to use a pessimistic locking scheme. I agree with you about having a look at queuing the entity state and version field changes. With respect to running all updates even after a concurrency exception I don't think it should be necessary. OC violations should be very rare and if you're getting multiple violations per flush you may want to rethink your locking strategy - maybe using something like Course Grained Lock? Cheers, Andrew. |
|
|
|
|
Hi, I have installed the latest Beta of LS and I am looking to handling optimistic concurrency with manually instead of relying on the built-in screens LS generates to handle. Unable to find something new! Is this coming soon? Maria Reese |
|
|
|
