10.3.3. Locking policy
Locks in JBoss Transaction Service are not special system types. They are, instead, instances of other JBoss Transaction Service objects. The
Lock
class is derived from StateManager
so that locks can be made persistent and can be named in a simple way. Furthermore, the LockManager
class does not know about the semantics of the actual policy for granting lock requests. Instances of the Lock
class maintain this information, and provide the conflictsWith
method, which LockManager
uses to determine whether two locks conflict. This separation allows you to derive new lock types from the basic Lock
class and provides appropriate definitions of the conflict operations, allowing enhanced levels of concurrency.
public class LockMode { public static final int READ; public static final int WRITE; }; public class LockStatus { public static final int LOCKFREE; public static final int LOCKHELD; public static final int LOCKRETAINED; }; public class Lock extends StateManager { public Lock (int lockMode); public boolean conflictsWith (Lock otherLock); public boolean modifiesObject (); public boolean restore_state (InputObjectState os, int ObjectType); public boolean save_state (OutputObjectState os, int ObjectType); public String type (); . . . };
The
Lock
class provides a modifiesObject
method, which LockManager
uses to determine a call or method is needed to grant a locking request. This allows locking modes other than simple read and write to be supported. The supplied Lock
class supports the traditional multiple reader/single writer policy.