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.