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

Offline Lock pattern is an application-level locking mechanism, you have to make
several other design decisions, including how to lock it, when to lock it, and where
to store the locks. Let's look at each of the decisions you must make in turn.

13.6.1 Deciding what to lock

One decision that you must make is what to lock. In many use cases, there is a class
that obviously needs to be locked. For example, in the Modify Order use case it's
the order that must be locked because it is the object being edited. Sometimes,
however, the class that must be locked is less obvious. Consider, for example, a use
case that edits only the order's line items. You could lock the individual line items
but this would require locking multiple objects, which is messy to implement. A bet-
ter approach is to lock a group of related objects using a single lock—the so-called
Coarse-Grained Lock pattern [Fowler 2002]. In this example, you would lock the
order instead of the individual line items. As well as being easier to implement, it
avoids the problem of locking multiple objects individually, which can lead to dead-
locks. See [Fowler 2002] for a discussion of the details of using this pattern.

13.6.2 Determining when to lock and unlock the data

In addition to deciding what to lock, you must identify which domain service
methods and transaction scripts must lock and unlock data. The method or meth-
ods that lock the data are those that are called to start the use case and load the
data that is being edited. Similarly, the data must be unlocked by those methods
that are called at the end of the use case. Methods that are called during the use
case can verify that the lock is still held but are not required to do so.

13.6.3 Choosing the type of lock

Another decision you must make when implementing this pattern is which type of
lock to use. The simplest kind of lock is an exclusive write lock . A transaction that
wants to update the data claims the lock and prevents others from editing it.
Transactions that only read the data do not have to claim the lock and are not
blocked waiting for the owner of the lock to finish editing the data. Exclusive
write locks work well for many use cases, so they are the only kind of lock we'll
describe in detail.
There are, however, other kinds of locks that are useful in some situations.
Let's suppose that the data being edited can become inconsistent during the use
case. The application could, for example, apply the user's changes immediately
rather than saving them until the end and applying them in a final transaction.
One way to prevent other transactions from reading the inconsistent data is to use