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

when writing new code you might forget to use the pattern. One potential solu-
tion is the Implicit Lock pattern [Fowler 2002], which automates the lock manage-
ment. However, implementing this pattern can be difficult because the business
logic determines when you must lock and unlock data. As a result, you often have
to rely on careful coding and lots of testing.

Requires a mechanism to forcibly release locks
In addition to globally impacting the application, this pattern requires you to
implement a mechanism to release the locks when a user abandons her session.
One solution is to implement a timeout mechanism. The application could
release the locks held by a user when the HttpSession times out. Alternatively, the
application could release locks that have been held for too long. However, the
trouble with timeouts is that if they are too long, users are prevented from getting
work done and if they are too short, users risk being timed out by accident.
For many applications, a better approach is to let users steal locks after warn-
ing them that the data they want to edit is locked by someone else. For example, if
a user attempts to edit an order that is locked by someone else, the application
can ask them to confirm that they really want to edit the order. Another possibility
is to only let users with administrative privileges steal locks. Which option is better
depends on the specific requirements of an application.

13.5.4 When to use this pattern

Because the Pessimistic Offline Lock guarantees that the user who edits the data
can save the changes, this pattern should be used when:

Data is read in one database transaction and updated in another.

■

The probability of conflicts is high.

■

The consequences of conflicts are severe.

■

Users typically do not abandon their sessions or it's feasible to implement a
lock cleanup mechanism.

■

Let's now look at the different decisions you must make when implementing this
pattern.

13.6 Pessimistic offline locking design decisions

When using database-level pessimistic locking, the database is responsible for the
implementation of the locking mechanism. The only thing that you get to decide
is what to lock and perhaps the kind of lock to use. But because the Pessimistic