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

try {
Order order = attachmentManager.attach(detachedOrder);
return new AcknowledgeOrderResult(
AcknowledgeOrderResult.OK, detachedOrder);
} finally {
lockManager
.releaseLock(Order.class.getName(),
detachedOrder.getId(),
owner);
}
}

Unlocks order

…
The getOrderToAcknowledge() method calls the LockManager to verify that the
order is unlocked. The isLocked() method is a new LockManager method, which
returns true if the specified object is locked by anyone. The acknowledgeOrder()
method has an owner parameter, which is passed to the LockManager . It calls
acquireLock() to lock the order before attaching the order. Afterwards, it calls
releaseLock() to unlock the order. If either method fails to acquire the lock, it
returns a status code of AcknowledgeOrderResult.LOCKED , which tells the presenta-
tion tier that the order is locked and cannot be changed.
As you can see, using the Pessimistic Offline Lock pattern in one use case
requires the other use cases that access the same data to use it as well. You might
even have to change existing code to call the lock manager if you implement a
new use case that requires the Pessimistic Offline Lock pattern. Although these
code changes can be substantial, they are unavoidable if you must prevent two
users from editing the same data simultaneously.
Using the Pessimistic Offline Lock pattern ensures that changes made to an
order will not be lost. The customer service representative will be able to save the
changes requested by the customer—and another happy customer will enjoy a
delicious meal.

13.8 Summary

There are two ways to handle concurrent updates in edit-style use cases that read
data in one database transaction and update it in another. One option is to use the
Optimistic Offline Lock pattern, which verifies that the data in the database is
unchanged since it was first read at the start of a use case. One way to implement
this pattern is to store the original version number or timestamp of the data being
edited as part of the session state and to verify that it is unchanged when updating it.