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

be extremely annoyed by having to discard several minutes' work, a much better
option is to use the Pessimistic Offline Lock .

2.6.2 Pessimistic Offline Lock pattern

The Pessimistic Offline Lock pattern handles concurrent updates across a
sequence of database transactions by locking the shared data at the start of the
editing process, which prevents other users from editing it. It is similar to the pes-
simistic locking mechanism described earlier except that the locks are imple-
mented by the application rather than the database. Because only one user at a
time is able to edit the shared data, they are guaranteed to be able to save their
changes. In chapter 13 you will learn more about when to use Pessimistic Offline
Lock pattern, examine some of the implementation challenges, and see how to
use it with i BATIS , JDO , and Hibernate.
Let's review the five design decisions. These decisions and their options are sum-
marized in table 2.1. In the rest of the topic you will learn more about each option,
examining in particular its benefits and drawbacks and how to implement it.

Table 2.1 The key business logic design decisions and their options

Decision Options

Business logic organization Domain Model pattern

Transaction Script pattern
Table Module pattern

Business logic encapsulation EJB Session Façade pattern

POJO Façade pattern
Exposed Domain Model pattern

Database access Direct JDBC

iBATIS
Hibernate
JDO

Concurrency in database trans-
actions

Ignore the problem
Pessimistic locking
Optimistic locking
Serializable isolation level

Concurrency in long-running
transactions

Ignore the problem
Pessimistic Offline Lock pattern
Optimistic Offline Lock pattern

Now that you have gotten an overview of the business logic and database access
design decisions, let's see how a development team applies them.