J2EE design decisions - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 46

easy to implement a pessimistic locking mechanism in an application that executes
SQL statements directly. However, as you would expect, using pessimistic locking in
a JDO or Hibernate application is even easier. JDO provides pessimistic locking as a
configuration option, and Hibernate provides a simple programmatic API for lock-
ing objects. Again, in chapter 12 you will learn when to use pessimistic locking,
examine its drawbacks, and see how to use it with i BATIS , JDO , and Hibernate.
In addition to handling concurrency within a single database transaction, you
must often handle concurrency across a sequence of database transactions.

2.6 Decision 5: handling concurrency
in long transactions

Isolated transactions, optimistic locking, and pessimistic locking only work within
a single database transaction. However, many applications have use cases that are
long running and that consist of multiple database transactions which read and
update shared data. For example, one of the use cases that you will encounter
later in this chapter is the Modify Order use case, which describes how a user edits
an order (the shared data). This is a relatively lengthy process, which might take
as long as several minutes and consists of multiple database transactions. Because
data is read in one database transaction and modified in another, the application
must handle concurrent access to shared data differently. It must use the Optimis-
tic Offline Lock pattern or the Pessimistic Offline Lock pattern, two patterns described
by Fowler [Fowler 2002].

2.6.1 Optimistic Offline Lock pattern

One option is to extend the optimistic locking mechanism described earlier and
check in the final database transaction of the editing process that the data has not
changed since it was first read. You can, for example, do this by using a version
number column in the shared data's table. At the start of the editing process, the
application stores the version number in the session state. Then, when the user
saves their changes, the application makes sure that the saved version number
matches the version number in the database.
In chapter 13 you will learn more about when to use Optimistic Offline Lock
pattern and how to use it with i BATIS , JDO , and Hibernate. Because the Optimistic
Offline Lock pattern only detects changes when the user tries to save their
changes, it only works well when starting over is not a burden on the user. When
implementing use cases such as the Modify Order use case where the user would