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

The user (customer service representative) selects the order to edit. The system
displays the order. The user updates the quantities, the delivery address and
time, and the payment information. The system displays the updated order. The
user saves his changes. The system updates the order.

displayed to the user, one or more other transactions read data to validate the
user's input, and the last transaction updates the order with the user's changes.
Although you could handle concurrent updates by using the Optimistic
Offline Lock pattern, this pattern only detects concurrent updates when the user
saves the order. While a user would only be mildly irritated if he had to reenter
changes during the Acknowledge Order use case, which involves only a small
amount of user input, it is not acceptable for the Modify Order use case. A cus-
tomer service representative could spend several minutes on the phone with a
customer changing the order only to discover that she could not save her
changes. Telling the customer to start over would be extremely frustrating for
everyone concerned.

13.5.2 Using the Pessimistic Offline Lock pattern

In use cases such as this where the probability of concurrent updates is high or the
consequences are severe, a better approach is to use the Pessimistic Offline Lock
pattern, which implements an application-level locking mechanism that allows
only one user to edit a particular piece of data at a time. Typically, either domain
model services or transaction scripts are responsible for locking and unlocking
the data because they are aware of when the use case begins and ends. The trans-
action script or service method that is called at the start of the use case to load the
data being edited would lock the data. The transaction script or service method
that is called at the end of the use case unlocks the data.
Figure 13.4 shows how the business logic for the Modify Order use case can use
the Pessimistic Offline Lock pattern to ensure that only one user can edit the
order at a time.
The first transaction, which loads the order to display to the user, locks the
order and the last transaction unlocks the order after updating with the user's
changes. If another user tried to edit the order, they would not be able to do so
because they could not claim the lock. In section 13.7 we will see that an applica-
tion typically claims and releases locks by inserting and deleting rows in an appli-
cation-level lock table.