Java Reference
In-Depth Information
database accesses. Later, at commit time, when Hibernate tries to update the
order it will throw an exception if the order has changed in the database since it
was first loaded.
As you can see, implementing the Optimistic Offline Lock pattern is relatively
straightforward because you can leverage the optimistic locking and detached
object mechanisms provided by JDO or Hibernate. However, for some use cases it
is not enough to prevent one user from overwriting another's changes and you
must use the Pessimistic Offline Lock pattern, which prevents two users from edit-
ing the same data simultaneously.
13.5 The Pessimistic Offline Lock pattern
We have seen that the Optimistic Offline Locking pattern is a partial solution to
the problem described at the start of this chapter. It prevents changes made to an
order from mysteriously disappearing. The application will display a message tell-
ing the customer service representative to start over. This is certainly better than
losing the changes, but it's still pretty irritating. We need a way of guaranteeing
that users can save their changes. To do that, we need to use the Pessimistic
Offline Lock pattern.
The Pessimistic Offline Lock pattern prevents concurrent updates by locking
the shared data while it is being edited. It is similar to pessimistic locking where
the transaction locks the data when it is read, which prevents others from access-
ing it, and releases the locks when it commits or rolls back. However, the key dif-
ference is that the Pessimistic Offline Lock pattern is an application-level
mechanism that works over multiple database transactions and the locks are
implemented by the application rather than the database. The application locks
the data when reading and displaying it to the user, and unlocks the data when
the user saves her changes.
13.5.1
Motivation
In order to understand why the Pessimistic Offline Lock pattern is necessary, let's
look at the Modify Order use case. This use case, which is more elaborate than the
Acknowledge Order use case, describes how a customer service representative can
change an order. It has the following specification:
The user can potentially take several minutes to change the order, and so like
the Acknowledge Order use case, this use case consists of multiple database trans-
actions. The first transaction loads the order from the database so that it can be
 
 
 
 
 
 
 
Search WWH ::




Custom Search