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

The application is unaware of how the persistence framework implements
optimistic locking. It even works with state comparison-based optimistic
locking.

■

It provides a simple way to lock an entire object graph, such as an order and
its line items, without having to explicitly store version numbers for each
object in the session state.

■

It simplifies the application by enabling the presentation tier to update the
detached object directly.

■

This approach also has drawbacks. As we have seen in chapter 7, the business logic
is less encapsulated because the presentation tier has access to the detached
objects. In addition, the session state can become bloated with detached objects
and recovering from offline optimistic locking failures can be tricky. Let's look at
those two problems.

Bloated session state
One potential problem with using detached objects to implement the Optimistic
Offline Lock pattern is that the session state can become bloated with graphs of
detached objects. Each graph of detached objects consists of detached objects
that are directly or indirectly referenced by the objects being edited. In a Hiber-
nate application, the detached object graph will contain all accessible objects that
were loaded by the application, including objects that were navigated to by the
business tier as well as objects that were eagerly loaded. For example, the business
logic for the Acknowledge Order use case must load the order's line items and its
restaurant in order to display on the Acknowledge Order screen. As a result, these
objects become part of the session state, which significantly increases the amount
of memory required to store it.
JDO gives you a lot more control over the structure of the object graph. By defin-
ing the appropriate fetch group, you can ensure that the detached object graph
contains only the objects being edited. However, this can require the business tier
to return at least two object graphs: one that contains the objects to store in the ses-
sion state and another that contains the data that is displayed to user. Sometimes it
is a lot easier to return a single object graph that contains both sets of objects.

Handling optimistic offline locking failures
Another issue is determining when an optimistic offline locking failure has
occurred, if the business tier has attached some objects and updated others within
the same transaction. The persistence framework throws the same exception
regardless of whether an optimistic offline locking failure or a regular optimistic