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
|
We have implemented an entity base class with LockVersion and the code throws OptimisticConcurrencyException when we would expect it to the first time a user saves stale data after another instance of the code saved changes on the same row "behind" the first instance of the code. Our code handles the exception, and notifies the user with a nice message box that this has occurred. If the user that recieved the OptimisticConcurrencyException clicks save a 2nd time after dismissing the error, we have found that the LockVersion on the entities has been incremented, and the queries issued succeed in overwriting the first users saved changes successfully without the OptimisticConcurrencyException. This is undesired behavior for two reasons: 1) It leaves the entity with inconsistent state 2) It clobbers the first users Is this expected behavior? If not, would it be possible to decrement the LockVersion or more preferably restore the state on the object in the result of a failure? |
|
|
Thanks for reporting this issue. I've committed a candidate fix for this, which will be included in the 11 June nightly build (available from about 1500 GMT). Let us know if you still see problems. |
|
|
Excellent news. Looking forward to that. |
|