Using offline locking patterns - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 494

Database transaction A.1 retrieves the Order and saves its version number as
part of the session state.

1

Database transaction B.1 retrieves and cancels the order, which incre-
ments the version number.

2

Database transaction A.2 attempts to update the order. Because the ver-
sion number was incremented by transaction B.1, the UPDATE statement
does not update any rows and the transaction fails.

3

As you can see, the Optimistic Offline Lock pattern is very similar to the optimistic
locking mechanism described in chapter 12. And, like that mechanism, this pattern
can also detect changes using a timestamp or by comparing old and new columns
instead of using a version number. What's more, as you will see a bit later, an appli-
cation that uses a persistence framework typically implements the Optimistic Offline
Lock pattern using the persistence framework's optimistic locking mechanism.

13.2.2 Benefits and drawbacks

The Optimistic Offline Lock pattern has a couple of advantages:

It is relatively easy to implement.

■

Unlike the Pessimistic Offline Lock pattern, there are no locks to clean up if
the user abandons the session, which is not uncommon in a web application.

■

However, there are the following drawbacks and issues:

Although the Optimistic Offline Lock pattern prevents changes from being
overwritten, it does not prevent two users from attempting to update the
same order. In the scenario described earlier, the user of transaction A
would not be able to save her work and she would have to start over. In
some situations this can be unacceptable—if, for example, a user has
invested a lot of time making the changes.

■

All transactions that update shared data must increment the version num-
ber whenever they update a row, including those that do not use the Opti-
mistic Offline Lock pattern.

■

13.2.3 When to use this pattern

The Optimistic Offline Lock pattern should be used when:

Data is read in one database transaction and updated in another.

■

The probability of conflicts is low and the consequences of redoing the
changes are minimal.

■