Section 16.3. Optimistic Concurrency


16.3. Optimistic Concurrency

Consider the following archetypical example. A user selects a widget to edit. The application displays details about the widget for editing. The user changes the widget's attributes and submits the changes. This process involves two distinct transactions. The application obtains the widget for the user to edit in the first transaction. The application updates the widget in the database using a second transaction, committing the first user's changes. Now, what if another user edited the same widget before the second transaction of the first user was committed. The second user's changes are lost! This application behavior is often referred to as the last update/write wins policy. It's also sometimes called the lost update problem. It's likely that this behavior is not intentional since the changes are lost silently.

Why don't transaction isolation levels help here? Transaction isolation levels apply only to concurrent transactions. In our case, we're talking about distinct transactions that conflict with each other in terms of outcomes. If the application performed both operations within a single transaction, isolation levels could be used to ensure that two users working concurrently would not conflict with each other. But with the work broken down into two separate transactions for each user, the lost update problem is a possibility.

One simple and potentially elegant solution to this problem is optimistic concurrency. Before every update, you simply ensure that another transaction has not updated the data. There are many ways to ensure this behavior. The most common way is to use a version identifier. Revisiting the archetypical example, a user selects a widget to edit. The application displays the details about the widget to the user for editing. Additionally, the application also keeps track of the version identifier associated with the widget, perhaps using a field in the relational database storing the widget data. The user changes the widget's attributes and submits the changes along with the original version identifier. The changes are successful only if the submitted version identifier matches the version identifier in the database. Upon successful update, the version identifier is incremented. However, what if a second user edits the same widget before the first user submits her changes? The action by the second user updates the version identifier. When the first user submits the changes, the application rejects the update since the version identifiers do not match. This prevents the first user from overriding the changes made by the second user. Thus, the changes made by the second user are not lost! Typically, the first user is presented with the state of the widget as-is (or a merged state) and is asked to submit the update again.

Using a version identifier is a very common technique. Other techniques, with their own advantages and disadvantages, are possible including using a timestamp, using checksums, and checking all the data in the previous row.

This technique is called "optimistic" concurrency because the application is designed to be optimistic that the likelihood of conflict is minimal by splitting its operations into two separate, independent transactions. An alternative approach is pessimistic concurrency: you assume that the likelihood of contention for data is highly likely, and you prevent the conflict explicitly by using a single transaction and high isolation levels or by locking the data under contention when it is accessed by the first user.

The J2EE specifications do not specify a standard implementation of optimistic concurrency. Instead, your application code implements it, using approaches such as the one just described. In addition, the application can delegate the concurrency-handling logic to the database, using database triggers and/or stored procedures. Application server vendors may also provide proprietary extensions that implement and support optimistic concurrency.



Java Enterprise in a Nutshell
Java Enterprise in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596101422
EAN: 2147483647
Year: 2004
Pages: 269

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net