1.2.8. The class hierarchy

The principal classes which make up the class hierarchy of TxCore are depicted below.
StateManager		// Basic naming, persistence and recovery control
                LockManager		// Basic two-phase locking concurrency control service
                User-Defined Classes
                Lock			// Standard lock type for multiple readers/single writer
                User-Defined Lock Classes
                AbstractRecord		// Important utility class, similar to Resource
                    RecoveryRecord	            // handles object recovery
                    LockRecord		// handles object locking
                    RecordList		// Intentions list
                    other management record types
                AtomicAction		// Implements transaction control abstraction
                    TopLevelTransaction
                Input/OutputBuffer // Architecture neutral representation of an objects’ state
                    Input/OutputObjectState	// Convenient interface to Buffer
                ObjectStore			// Interface to the object storage services
Programmers of fault-tolerant applications will be primarily concerned with the classes LockManager, Lock and AtomicAction. Other classes important to a programmer are Uid, and ObjectState. Most TxCore classes are derived from the base class StateManager, which provides primitive facilities necessary for managing persistent and recoverable objects. These facilities include support for the activation and de-activation of objects, and state-based object recovery. The class LockManager uses the facilities of StateManager and Lock to provide the concurrency control (two-phase locking in the current implementation) required for implementing the serialisability property of atomic actions. The implementation of atomic action facilities is supported by AtomicAction and TopLevelTransaction.
Most TxCore system classes are derived from the base class StateManager, which provides primitive facilities necessary for managing persistent and recoverable objects. These facilities include support for the activation and de-activation of objects, and state-based object recovery. The class LockManager uses the facilities of StateManager and provides the concurrency control required for implementing the serialisability property of atomic actions.
Consider a simple example. Assume that Example is a user-defined persistent class suitably derived from the LockManager. An application containing an atomic transaction Trans accesses an object (called O) of type Example by invoking the operation op1 which involves state changes to O. The serialisability property requires that a write lock must be acquired on O before it is modified; thus the body of op1 should contain a call to the setlock operation of the concurrency controller:
public boolean op1 (...)
{	
    if (setlock (new Lock(LockMode.WRITE) == LockResult.GRANTED)
    {
        // actual state change operations follow 
        ...
    }
}
The operation setlock, provided by the LockManager class, performs the following functions in this case:
  • Check write lock compatibility with the currently held locks, and if allowed:
  • Call the StateManager operation activate that will load, if not done already, the latest persistent state of O from the object store. Then call the StateManager operation modified which has the effect of creating an instance of either RecoveryRecord or PersistenceRecord for O depending upon whether O was persistent or not (the Lock is a WRITE lock so the old state of the object must be retained prior to modification) and inserting it into the RecordList of Trans.
  • Create and insert a LockRecord instance in the RecordList of Trans.
Now suppose that action Trans is aborted sometime after the lock has been acquired. Then the rollback operation of AtomicAction will process the RecordList instance associated with Trans by invoking an appropriate Abort operation on the various records. The implementation of this operation by the LockRecord class will release the WRITE lock while that of RecoveryRecord/PersistenceRecord will restore the prior state of O.
It is important to realise that all of the above work is automatically being performed by TxCore on behalf of the application programmer. The programmer need only start the transaction and set an appropriate lock; TxCore and Transactional Objects for Java take care of participant registration, persistence, concurrency control and recovery.