Java Reference
In-Depth Information
be mapped to the original table and a lock table. However, the overhead of
reading and updating the extra table could reduce performance.
The application must query multiple tables to determine which entities are
locked by a user.
Determining whether an object is locked can be tricky in an application
that uses a process-level cache because the in-memory object might not be
up to date. The application might have to somehow force the latest copy of
an object to be loaded.
Despite these drawbacks, however, storing locks in objects is sometimes the sim-
plest way to implement the Pessimistic Offline Lock pattern.
13.6.6
Handling locking failures
The sixth and final decision you must make when implementing the Pessimistic
Offline Lock pattern is what to do when one user tries to access (typically edit)
data that is locked by another user. When this happens, the attempt to claim the
lock will fail. For example, the acquireLock() method defined by the LockManager
you saw earlier will return false . The simplest and most effective way to handle
locking failures is for the business tier to return a status code or throw an excep-
tion indicating that the data could not be locked. Unlike when using database
transaction-level concurrency mechanisms, there is little point in having the busi-
ness tier automatically try again to claim the lock because locks are typically held
for a long time.
The presentation tier can then display an error message telling the user to try
again later or perhaps give the user the opportunity to steal the lock. A rich client
such as an Ajax UI running in the user's browser could, however, periodically re-
send the request that claims the lock.
In theory, deadlocks can occur if use cases lock multiple objects. Each user
would be waiting for the other to release locks. The simplest way to prevent dead-
locks is for the application to release all locks when it fails to claim a lock and
require the user to start over from the beginning. Of course, whether this is possi-
ble depends on the details of the use case.
Now that we have explored the various design issues you must address when
using the Pessimistic Offline Lock pattern, let's learn how to implement it in a
domain model-based design.
 
 
 
Search WWH ::




Custom Search