Quick Links to:
About this Page
Example Situation
To set the scene, here's a typical situation in our web applications:
- Dave pulls up data in his browser. Goes to lunch.
- Shahla pulls up same data, makes a change and saves. Changes are committed to the DB.
- Dave comes back from lunch, changes the data on his screen and saves. Changes are committed, overwriting Shahla's changes.
Obviously this isn't good; when Dave finally submits changes, we need the app to detect that someone else has changed the data, and to handle the situation appropriately. Two aspects to doing this are:
- Detection - how to detect a concurrent update
- Handling - what to do if we detect a concurrent update
We'll take these in reverse order:
Handling a Concurrent Update Situation
Detection
Chosen Solution
IMPORTANT: Load vs Get
There is a difference between Hibernate's load and get methods for retrieving data that is important in checking for concurrent updates:
with two sessions working with an object with the same identifier. Initial version for object in DB is 10.
Session 1 Session 2
--------- ---------
Load object
Wait a while..
Load object
Modify object property
[triggers db 'select' -
version read as 10]
Commit
[triggers db update,
version modified to 11]
Modify object property
[triggers db 'select' -
version read as 11]
Commit
[triggers db update,
version modified to 12]
We actually want session 1's commit to fail with an optimistic lock exception, but it will succeed here.
Using "get" instead of "load" works around the problem, because get will immediately issue a select, and the version numbers will be loaded at the correct times for the optimistic lock checking.
We actually want session 1's commit to fail with an optimistic lock exception, but it will succeed here.
Using "get" instead of "load" works around the problem, because get will immediately issue a select, and the version numbers will be loaded at the correct times for the optimistic lock checking.