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

ModifyOrderServiceResult.OK, order);
} else {
return new ModifyOrderServiceResult(
ModifyOrderServiceResult.NOT_LOCKED);

}
}

}

Let's look at the details:

B

The constructor takes a PendingOrderRepository , an OrderRepository , a Restau-
rantRepository , and a LockManager as parameters and stores them in fields.
The getOrderToModify() method first locks the Order by calling LockMan-
ager.acquireLock() .
The method then finds the Order by calling the OrderRepository and creates a
PendingOrder .
getOrderToModify() returns a ModifyOrderServiceResult .
The updateDeliveryInfo() method first verifies that the order is still locked by
calling LockManager.verifyLock() .
The method finds the PendingOrder and calls PendingOrder.updateDeliveryInfo() .
updateDeliveryInfo() returns a ModifyOrderServiceResult .
The saveChangesToOrder() method first verifies that the order is still locked.
The method updates the Order with the changes made by the user.
It then unlocks the Order and returns a ModifyOrderServiceResult .
The method cancelModifyOrder() verifies that the Order is still locked.
It then unlocks the Order by calling LockManager.releaseLock() .
As you can see, the business logic implemented by the domain model service
makes calls to the LockManager . The getOrderToModify() method, which is called
at the start of the use case, attempts to lock the order. If it cannot, then it returns
a status code indicating that the order is locked by another user. The user inter-
face can then display an error message to the user telling them to try again later.

C

D

E
F

G
H
I
J
1)
1!
1@