Java Reference
In-Depth Information
some tricky implementation issues when using one. Consequently, you might want
to consider storing locks in the objects themselves.
Storing locks in objects
Instead of using a centralized lock manager, an application can store a lock in each
object. Each class that supports pessimistic offline locking has a lock field, which
stores the identity of the lock's owner. The transaction script or domain service
method claims the lock by setting this field and releasing this lock by setting it to null.
A
JDBC
or i
BATIS
application can atomically claim a lock by executing a
SQL
UPDATE
statement, but an application that uses a persistence framework must load
an object in order to determine whether it is locked, set the lock field, and write it
back to the database. This means that acquiring a lock is not an atomic action and
the application must instead use database-level optimistic or pessimistic locking or
a serializable transaction in order to detect concurrent updates. However, because
an application is likely to already be using one of these mechanisms, this is usually
not a problem.
Benefits and drawbacks of storing locks in objects
This approach has some benefits:
The application doesn't have to implement an additional mechanism for
persisting locks.
■
It is easy for an application to determine whether an object is locked—it sim-
ply checks the lock field. Business transactions that consist of a single data-
base transaction can verify that an object is unlocked by checking the lock
field rather than claiming and releasing a lock. Also, queries can find locked
or unlocked objects by including the lock field in the query's
where
clause.
■
It avoids the problem encountered when using a lock manager and imple-
menting locks in an application that uses i
BATIS/JDBC
and
JDO
objects that
use datastore identity.
■
There are, however, a number of drawbacks and issues with this approach:
The decision as to whether a class supports locking must be done up front.
There is more code to maintain because lock management code is dupli-
cated in every class that can be locked.
■
Existing tables must be changed to add a lock column, which might not be
possible when working with a legacy schema. Alternatively, each class could
■
Search WWH ::
Custom Search