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

Having decided to use Spring, the team must now decide between using POJO
façades and the exposed domain model. After spending a lot of time discussing
these two options, they decide that the exposed domain model approach is too
radical and that they are more comfortable using a POJO façade.
Accessing the database
Because the team has decided to use a domain model, it must pick a persistence
framework. It would simply be too much work to persist the domain model with-
out one. On its last project, the team used EJB CMP because, despite its glaring
deficiencies, it was at that time the most mature solution. JDO was still in its
infancy and the team had not yet heard of Hibernate. However, that was quite
some time ago, and since then the team members have all read a few articles
about JDO and Hibernate and decide that they are powerful and mature technol-
ogies. They are excited that they do not have to use entity beans again. After an
animated discussion, the team picks JDO because its company prefers to use stan-
dards that are supported by multiple vendors. It hopes, however, to use Hibernate
on some other project in the future.
Handling concurrent updates
The Food to Go application, like many other enterprise applications, is a multiuser
application, which means that multiple transactions will access the same data con-
currently. For example, two transactions could attempt to update the same order
simultaneously. Therefore, it's essential to have a concurrency strategy. After
reviewing the three options—isolated database transactions, optimistic locking,
and pessimistic locking—the team picks optimistic locking because they have had
experience with it and know that it performs well. Moreover, it is supported by
JDO , which means that using it involves a simple configuration option.
Handling offline concurrency
Some of the application's use cases, such as the Modify Order use case, are long-
running application transactions where data read in one database transaction is
updated in another database transaction. In order to prevent two users from edit-
ing the same order simultaneously and overwriting each other's changes, it's
important to implement an offline concurrency mechanism. The Optimistic
Offline Lock pattern is easier to implement, especially because the application
can leverage the optimistic locking mechanism provided by the persistence frame-
work. However, the team decides to use the Pessimistic Offline Lock pattern for