Concurrent Database Updates

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:

1. Detection - how to detect a concurrent update
2. 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:

• load does not issue a SQL SELECT statement to retrieve data. It simply creates a proxy object that follows the structure of the relevant domain class.
• get issues an immediate SQL SELECT statement, creating a new domain class containing the data read from the database.

The reason this is important for concurrent update checking is that a proxy object generated by a load will not contain the version information we need. Our scheme depends on the version being loaded at the start of a

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.

Further Reading