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

an exclusive lock. All transactions that read and write the shared data must claim
an exclusive lock, which allows only one transaction at a time to access the data.
This ensures that transactions only see consistent data and that only one transac-
tion can update the data at a time.
The trouble with using an exclusive read lock is that it can reduce performance.
A transaction that only reads the data will block other transactions that also want to
only read the data. A more sophisticated approach is to use read/write locks . Trans-
actions that read the data claim read locks and transactions that update the data
claim write locks. The shared data can have multiple read locks or one write lock.
This allows multiple transactions to read the data but only one transaction to edit
it. Furthermore, it prevents the data from being read and edited at the same time.
This approach preserves data consistency without reducing performance as much
as an exclusive read lock, but can be complicated to implement.

13.6.4 Identifying the lock owner

The fourth decision you must make when implementing the Pessimistic Offline
Lock pattern is what to use as the identity of the lock owner. In a web application,
one option is to use the HttpSession ID as the lock owner. The presentation tier
passes the HttpSession ID to the business tier as part of each request. This approach
is useful if, for example, users are accessing the application anonymously. One
limitation of using the session ID is that, because it is a cryptic string, it cannot be
used to determine the person who owns the lock.
Another option is to use the user ID as the lock owner. The presentation tier
could pass the user ID as a parameter when it calls the business tier. Alternatively,
the business tier can call a security framework-specific API such as Acegi Security's
SecurityContextHolder to get the identity of the user, which is more secure and
eliminates the need for the presentation tier to provide it. One limitation of using
the user ID is that users must be logged in, which means this approach cannot be
used in applications that have anonymous users. In addition, portability can be an
issue because how you get the user ID depends on the security framework. Despite
these drawbacks, it is a useful approach.
For simplicity, the example that you will see later in this chapter has the pre-
sentation tier pass in the user ID .

13.6.5 Maintaining the locks

You must also decide how to maintain the locks. An application that runs on a sin-
gle application server can implement an in-memory locking mechanism such as a
singleton hash table. However, because most enterprise applications are clustered,