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

Some JDO implementations require the application get the version number
or timestamp by calling JDOHelper.getVersion() instead of simply getting it
from a field. This makes the code more complicated and dependent on the
JDO API s.

■

Editing a graph of objects requires the application to keep maintain multi-
ple version numbers or timestamps, which can be tricky.

■

It is not practical to use this approach when the persistence framework
implements optimistic locking using state comparison because you would
have to write tedious and error-prone code to store a copy of the object in
the session state and perform a field-by-field comparison before updating it.

■

When to use it
You should this approach when:

The object that is being updated has an accessible version number or time-
stamp field.

■

The application updates a small number of objects.

■

It is important to encapsulate the business logic.

■

It is important to minimize the size and complexity of the session state.

■

We won't show an example of implementing the Optimistic Offline Lock pattern
with an object version number because in many Hibernate and JDO applications
it's a lot easier to implement this pattern using detached objects.

13.3.2 Using detached objects

A detached object is an object that is no longer persistent but keeps track of its
persistent identity and contains data from the database, including references to
other detached objects. Because detached objects also keep track of their version
number or timestamp, they are a convenient way to implement the Optimistic
Offline Lock pattern. When the application loads an object that it will later
update, it stores a detached copy of the object as part of the session state. Later,
when the user saves the changes the application updates the object and reattaches
it. The persistence framework uses its optimistic locking mechanism to verify that
the database is unchanged since the object was detached. It will throw an excep-
tion if the object has been changed in the database.
Detached objects work well with an edit-style use case such as the Acknowledge
Order use case and can make it easier for the presentation tier to pass the user's
changes to the business tier. The business tier returns the detached object to the