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

The verifyLock() method verifies that the caller owns the lock by executing
the following SQL statement:

SELECT count(*)
FROM OFFLINE_LOCK
WHERE CLASS_ID = ? AND PK = ? AND OWNER = ?
It executes the SQL SELECT by calling SqlMapClientTemplate.select() . It throws a
LockManagerException if the lock does not exist or is owned by someone else.
The releaseLock() method releases a lock by executing the following SQL
statement:

DELETE FROM OFFLINE_LOCK WHERE CLASS_ID = ? AND PK = ? AND OWNER = ?
It executes this DELETE statement by calling SqlMapClientTemplate.delete() . It
throws a LockManagerException if the lock does not exist or is owned by someone else.
This is a very simple implementation of the lock manager. A more elaborate
implementation could, for example, track when locks are acquired and allow for
old locks to be stolen.

13.7.2 Implementing the domain service

Now that you have seen how to implement a lock manager, let's look at an exam-
ple of business logic that uses it. The business logic of the Modify Order use case
is implemented by the ModifyOrderService . The ModifyOrderService is a domain
model service that is invoked by either a POJO façade or the presentation tier. It
calls various other domain objects, including Order and OrderRepository , and
uses the LockManager to lock and unlock orders.
ModifyOrderService defines several methods that handle requests from the
presentation tier, including:
■ getOrderToModify() is called at the start of the use case when the user
decides to edit an order. It verifies that the order can be edited and then
locks it.
■ updateQuantities() is called when the user changes the line item quanti-
ties. It verifies that the order is still locked and saves the new quantities.
■ saveChangesToOrder() is called when the user saves her changes. It verifies
that the order is still locked, updates it, and then unlocks it.
■ cancelModifyOrder() is called when the user gives up editing the order. It
unlocks the order.

Because the process of editing an order is similar to the process of placing an
order, the ModifyOrderService uses a PendingOrder to keep track of the changes