This topic has not yet been written. The content below is from the topic description.
However, as shown in Figure 1.1, “TxCore Class Hierarchy�, by inheriting from the Lock class, you can provide your own lock implementations with different lock conflict rules to enable type specific concurrency control. Lock acquisition is, of necessity, under programmer control, since just as StateManager cannot determine if an operation modifies an object, LockManager cannot determine if an operation requires a read or write lock. Lock release, however, is under control of the system and requires no further intervention by the programmer. This ensures that the two-phase property can be correctly maintained. public class LockResult { public static final int GRANTED; public static final int REFUSED; public static final int RELEASED; }; public class ConflictType { public static final int CONFLICT; public static final int COMPATIBLE; public static final int PRESENT; }; public abstract class LockManager extends StateManager { public static final int defaultRetry; public static final int defaultTimeout; public static final int waitTotalTimeout; public final synchronized boolean releaselock (Uid lockUid); public final synchronized int setlock (Lock toSet); public final synchronized int setlock (Lock toSet, int retry); public final synchronized int setlock (Lock toSet, int retry, int sleepTime); public void print (PrintStream strm); public String type (); public boolean save_state (OutputObjectState os, int ObjectType); public boolean restore_state (InputObjectState os, int ObjectType); protected LockManager (); protected LockManager (int ot); protected LockManager (int ot, int objectModel); protected LockManager (Uid storeUid); protected LockManager (Uid storeUid, int ot); protected LockManager (Uid storeUid, int ot, int objectModel); protected void terminate (); }; The LockManager class is primarily responsible for managing requests to set a lock on an object or to release a lock as appropriate. However, since it is derived from StateManager, it can also control when some of the inherited facilities are invoked. For example, LockManager assumes that the setting of a write lock implies that the invoking operation must be about to modify the object. This may in turn cause recovery information to be saved if the object is recoverable. In a similar fashion, successful lock acquisition causes activate to be invoked.