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

Users invariably need to edit data that is stored by an enterprise application. For
example, let's imagine that you are a Food to Go customer and, just after placing
an order for food from your favorite Indian restaurant, you realize that you need
to order more. You could phone in and have a customer service representative
change an order to add the extra Naan bread, some Tandoori Portobello Mush-
rooms, and some Ras Malai. But how would you feel if the system mysteriously lost
the changes to your order? Most likely, you would be very disappointed that you
didn't get all the food you had ordered. What's worse, you might even be discour-
aged from using Food to Go again. To keep their customers happy, Food to Go
must prevent this kind of concurrency problem when users edit data.
Although some use cases, like the one we looked at in the previous chapter,
consist of a single database transaction, many others consist of a series of database
transactions and involve user input. For example, every enterprise application
that I have developed had screens that allow the user to edit data from the data-
base. Because the user could spend a few minutes editing the data, the opportu-
nity exists for concurrent updates. The application must handle the scenario
where two users attempt to edit the same data and prevent the same kinds of
inconsistencies and problems described in the previous chapter. The challenge is
how to handle concurrent access across a sequence of transactions.
Neither serializable transactions nor pessimistic locking can work across a
sequence of transactions. Instead, you must either extend the optimistic locking
mechanism described in chapter 12 and check that data is unchanged before updat-
ing it, or implement an application-level locking mechanism to lock the data at the
start of the use case and prevent other users from updating. The first approach is
what Fowler calls the Optimistic Offline Lock pattern, and the second approach is
what he calls the Pessimistic Offline Lock pattern [Fowler 2002].
In this chapter, we explain why you need to use the Optimistic Offline Lock
and Pessimistic Offline Lock patterns. You will learn about the benefits and draw-
backs of these two patterns and how to decide which one to use. We show you how
to implement these patterns in JDO and Hibernate applications using the
Acknowledge Order and Modify Order use cases as examples.
13.1 The need for offline locking
To understand why an application must use an offline locking pattern, let's look at
an example of an edit-style use case, which is an extremely common kind of use
case in which the user edits persistent data. Such a use case begins with the appli-
cation retrieving data from the database and presenting it to the user. The user
then changes the data and the application updates database with their changes.