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

This approach is also more flexible. We don't have to build the locking strat-
egy into the domain model classes ahead of time. The lock management
can be handled by the service classes instead.

■

The mechanism for claiming a lock is simple and easy to understand since a
lock manager can atomically claim a lock using an INSERT statement.

■

There are, however, a couple of drawbacks and issues to consider when using a
lock manager:

Using a lock manager makes the design more complicated. All business
transactions, even ones that consist of a single database transaction, must
claim and release locks. Also, determining whether an object is locked
involves a database query rather than simply checking a flag field.

■

Locking objects that are retrieved using a query or by navigation is tricky
because the application must execute the query in order to know which
objects to lock and consequently loads the objects before locking. As we
described earlier, an application must use either pessimistic or optimistic
locking to ensure that it uses the current version of the data and to prevent
lost updates. Or, the application must reread the data after locking it to ver-
ify that it hasn't changed.

■

There are also some additional issues to consider when using a JDBC/ i BATIS -
based lock manager with a persistence framework:

Sometimes an application must execute a query that includes or excludes
locked data. For example, the query that is used in the Send Orders use
case to find orders that are ready to send should ideally ignore locked
orders. A SQL query can ignore locked orders by simply doing a join with
the lock table. However, if the application uses a persistence framework
query, then the lock table must be mapped to a class in order for it to be ref-
erenced by the query.

■

Enabling JDBC/ i BATIS code and JDO code to share a lock manager is tricky
if the JDO code uses datastore identity. As described in chapter 5, the JDO
code does not have access to the object's primary key and the JDBC code
does not have access to the object's JDO identity. In order to lock data that is
accessed by both JDBC and JDO code, the application must use some other
unique identifier to lock the data.

■

A lock manager is a centralized and reusable mechanism for implementing the
Pessimistic Offline Lock pattern. However, as you have seen, you need to address