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

The other option is to use database-level optimistic locking. After claiming the
lock, transaction A performs an optimistic locking check to verify that the order
was unchanged. How this is done depends on the persistence framework. A
Hibernate application can call Session.lock() with a lock mode of LockMode.READ
to verify that an object is unchanged in the database. A JDO application would
have to make a possibly dummy modification to the object in order to cause the
JDO implementation to perform the check at commit time.

Implementing a lock manager
Because of the benefits of using a persistence framework, you might expect to
implement the lock manager with a persistence framework. You could map a Lock
class to the OFFLINE_LOCK table and claim and release locks by creating and
deleting objects. However, this approach is not as simple as it might appear. It can
be impossible for the business tier to handle locking errors because they will be
reported as commit-time exceptions by those persistence frameworks that do not
insert objects until commit time. In addition, the application must, as we just saw,
use a database transaction-level concurrency mechanism because data is read
before the lock is claimed at commit time.
Consequently, the easiest way to implement a lock manager is to use SQL
directly. The lock manager can use i BATIS or JDBC to atomically claim a lock by exe-
cuting an INSERT statement and release one or more locks by executing a DELETE
statement. In addition to being simple and easy to understand, a JDBC/ i BATIS lock
manager is more reusable because it is not coupled to any particular persistence
framework. In 13.7.1, we will look at an i BATIS implementation of a LockManager .

Benefits and drawbacks of using a lock manager
Implementing the Pessimistic Offline Lock pattern with a lock manager approach
has a number of benefits:

An application can lock an object using only its ID , which means that it can
first lock the object and then read it, which avoids the problem of stale data.
In addition, the application can lock entities that have been deleted or not
yet inserted.

■

Lock management is centralized. The lock management code is only in the
lock manager rather than in every class. The locks are stored in a single data-
base table, which makes it easy to see which objects are locked and by whom.

■