Jacob Severson
2014-03-05 21:14:45 UTC
Hi All,
A colleague discovered something interesting in regard to optimistic
locking - hoping for a little discussion on it. Originally this was found
to be true on updates with mongo, but I built a toy project to confirm it
exists relationally also:
1) User 1 queries an object and starts to update
2) User 2 in the meantime queries same object, updates, and saves
3) User 1 tries to save and gets an OptimisticLockingException as expected
4) Even though user 1 got the exception, their object's version number is
still incremented. Because of this, if they are able to save again, it will
succeed and overwrite user 1's data.
I could see this making sense, but it would also seem like a good idea to
not increment the version before the read (which throws the exception when
null). That way the user would be forced to refresh and have a fresh read
regardless of how the exception was handled.
Anyone have more insight on this? Thanks!
A colleague discovered something interesting in regard to optimistic
locking - hoping for a little discussion on it. Originally this was found
to be true on updates with mongo, but I built a toy project to confirm it
exists relationally also:
1) User 1 queries an object and starts to update
2) User 2 in the meantime queries same object, updates, and saves
3) User 1 tries to save and gets an OptimisticLockingException as expected
4) Even though user 1 got the exception, their object's version number is
still incremented. Because of this, if they are able to save again, it will
succeed and overwrite user 1's data.
I could see this making sense, but it would also seem like a good idea to
not increment the version before the read (which throws the exception when
null). That way the user would be forced to refresh and have a fresh read
regardless of how the exception was handled.
Anyone have more insight on this? Thanks!