Java Reference
In-Depth Information
bb private boolean lockOrder(String caller, Order order) {
return lockManager.acquireLock(Order.class.getName(),
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb order.getId(), caller);
bb }
bb private void unlockOrders(String caller, Collection orders) {
for (Iterator it = orders.iterator(); it.hasNext();) {
Order order = (Order) it.next();
lockManager.releaseLock(Order.class.getName(), order.getId(),
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb caller);
}
}
The sendOrders() method iterates through the result of the query and tries to
lock each order. It ignores orders that cannot be locked. After locking the order,
it sends it to the restaurant and updates it. Before returning, this method unlocks
all of the locked orders. The code reads objects before locking and so could
potentially read stale data and overwrite changes made by other transactions. It
must, for the reasons we saw in section 13.6.5, use one of the database transaction-
level concurrency mechanisms such as optimistic locking to avoid doing this.
One way to improve this code is to retrieve the orders with a query that ignores
the ones that are locked. The application must still lock the orders it retrieves to
prevent another transaction from attempting to update them, but excluding the
locked orders from the query prevents the application from loading them unnec-
essarily. The transaction script-based implementation of the Send Orders to Res-
taurant use case can use a SQL query that does a join between the
PLACED_ORDER and OFFLINE_LOCK tables. The domain model version would
need to map the OFFLINE_LOCK table to a class so that it can use a persistence
framework query that excludes locked orders.
Changing the Acknowledge Order use case
The Acknowledge Order use case is another use case that updates orders. There
are a couple of different ways we can change the Acknowledge Order use case
code to work with pessimistic offline locking. One option is to implement this use
case using the Pessimistic Offline Locking pattern instead of the Optimistic
Offline Locking pattern. Doing this is easy, but it means that another set of users
(i.e., restaurants) will hold locks on orders. Furthermore, because unlike customer
service representatives they are outside of the direct control of the company, these
 
Search WWH ::




Custom Search