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

public int getVersion() {
return version;
}
The O/R mapping for the Order class would map the version field to a database
column and tell the persistence framework to maintain the version number in the
version field. When the code that implements the Acknowledge Order use case
loads the object at the start of the use case, it calls Order.getVersion() and stores
the returned value in the HttpSession .
Later on, when the user confirms that she wants to acknowledge the order, the
application will execute code that looks something like this:

int originalVersion = … // from HttpSession
Order order = orderRepository.findOrder(orderId);
if (order.getVersion() == originalVersion) {
order.noteAccepted(notes);
…
} else {
// fail
…
}
This code fragment loads the order from the database and verifies that its current
version is the same as the one that was stored in the HttpSession at the beginning
of the use case. It only updates the order if it is unchanged. Otherwise, it will
return an error code to the caller indicating that the order had been changed by
someone else.

Benefits and drawbacks
This approach has the following benefits:

It is simple to implement.

■

It stores only a small amount of data in the session state.

■

It provides better encapsulation than using detached objects because the
presentation tier can only access the business logic via a façade or service.

■

Recovering from offline optimistic locking failures can be more straightfor-
ward than with detached objects because the changes are detected by the
application instead of the persistence framework.

■

But keep in mind these drawbacks: