In keeping with the object-oriented view, the mechanisms needed to construct reliable distributed applications are presented to programmers in an object-oriented manner. Some mechanisms need to be inherited, for example, concurrency control and state management. Other mechanisms, such as object storage and transactions, are implemented as TxCore objects that are created and manipulated like any other object.

TxCore exploits object-oriented techniques to present programmers with a toolkit of Java classes from which application classes can inherit to obtain desired properties, such as persistence and concurrency control. These classes form a hierarchy, part of which is shown in Figure 2.1, “TxCore Class Hierarchy” and which will be described later in this document.

Figure 2.1. TxCore Class Hierarchy

TxCore needs to be able to remember the state of an object for several purposes.

Since these requirements have common functionality they are all implemented using the same mechanism: the classes InputObjectState and OutputObjectState. The classes maintain an internal array into which instances of the standard types can be contiguously packed or unpacked using appropriate pack or unpack operations. This buffer is automatically resized as required should it have insufficient space. The instances are all stored in the buffer in a standard form called network byte order, making them machine independent. Any other architecture-independent format, such as XDR or ASN.1, can be implemented simply by replacing the operations with ones appropriate to the encoding required.

Implementations of persistence can be affected by restrictions imposed by the Java SecurityManager. Therefore, the object store provided with TxCore is implemented using the techniques of interface and implementation. The current distribution includes implementations which write object states to the local file system or database, and remote implementations, where the interface uses a client stub (proxy) to remote services.

Persistent objects are assigned unique identifiers, which are instances of the Uid class, when they are created. These identifiers are used to identify them within the object store. States are read using the read_committed operation and written by the write_committed and write_uncommitted operations.

At the root of the class hierarchy is the class StateManager. StateManager is responsible for object activation and deactivation, as well as object recovery. Refer to Example 2.1, “Statemanager” for the simplified signature of the class.

 public abstract class StateManager

{

    public boolean activate ();

    public boolean deactivate (boolean commit);


    public Uid get_uid (); // objects identifier.


    // methods to be provided by a derived class


    public boolean restore_state (InputObjectState os);

    public boolean save_state (OutputObjectState os);


    protected StateManager ();

    protected StateManager (Uid id);

};

If an object is recoverable or recoverable and persistent, then StateManager invokes the operations save_state while performing deactivate, and restore_state while performing activate,) at various points during the execution of the application. These operations must be implemented by the programmer since StateManager cannot detect user-level state changes. This gives the programmer the ability to decide which parts of an object’s state should be made persistent. For example, for a spreadsheet it may not be necessary to save all entries if some values can simply be recomputed. The save_state implementation for a class Example that has integer member variables called A, B and C might be implemented as in Example 2.2, “save_state Implementation”.

public boolean save_state(OutputObjectState o)

{

    if (!super.save_state(o))

        return false;


    try

        {

            o.packInt(A);

            o.packInt(B);

            o.packInt(C));

}

catch (Exception e)

    {

        return false;

    }


return true;

}

A persistent object not in use is assumed to be held in a passive state, with its state residing in an object store and activated on demand. The fundamental life cycle of a persistent object in TXOJ is shown in Figure 2.2, “Life cycle of a persistent Object in TXOJ”.

[D]

Figure 2.2. Life cycle of a persistent Object in TXOJ

The concurrency controller is implemented by the class LockManager, which provides sensible default behavior while allowing the programmer to override it if deemed necessary by the particular semantics of the class being programmed. As with StateManager and persistence, concurrency control implementations are accessed through interfaces. As well as providing access to remote services, the current implementations of concurrency control available to interfaces include:

The primary programmer interface to the concurrency controller is via the setlock operation. By default, the runtime system enforces strict two-phase locking following a multiple reader, single writer policy on a per object basis. However, as shown in Figure 2.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.

Example 2.3, “Example Class” shows how to try to obtain a write lock on an object.

public class Example extends LockManager

{

    public boolean foobar ()

    {

        AtomicAction A = new AtomicAction;

        boolean result = false;


        A.begin();


        if (setlock(new Lock(LockMode.WRITE), 0) == Lock.GRANTED)

            {

                /*

                 * Do some work, and TXOJ will

                 * guarantee ACID properties.

                 */


                // automatically aborts if fails


                if (A.commit() == AtomicAction.COMMITTED)

                    {

                        result = true;

                    }

            }

        else

            A.rollback();


        return result;

    }

}

The transaction protocol engine is represented by the AtomicAction class, which uses StateManager to record sufficient information for crash recovery mechanisms to complete the transaction in the event of failures. It has methods for starting and terminating the transaction, and, for those situations where programmers need to implement their own resources, methods for registering them with the current transaction. Because TxCore supports sub-transactions, if a transaction is begun within the scope of an already executing transaction it will automatically be nested.

You can use TxCore with multi-threaded applications. Each thread within an application can share a transaction or execute within its own transaction. Therefore, all TxCore classes are also thread-safe.

{

    . . .

    O1 objct1 = new objct1(Name-A);/* (i) bind to "old" persistent object A */

    O2 objct2 = new objct2();  /* create a "new" persistent object */

    OTS.current().begin();     /* (ii) start of atomic action */


    objct1.op(...);           /* (iii) object activation and invocations */

    objct2.op(...);

    . . .

    OTS.current().commit(true);  /* (iv) tx commits & objects deactivated */

}              /* (v) */

The principal classes which make up the class hierarchy of TxCore are depicted below.

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 required for implementing the serializability property of atomic actions. The concurrency control consists of two-phase locking in the current implementation. The implementation of atomic action facilities is supported by AtomicAction and TopLevelTransaction.

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 serializability property requires that a write lock must be acquired on O before it is modified. Therefore, 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 

        ...

    }

}

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 or PersistenceRecord will restore the prior state of O.

It is important to realize 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 TXOJ take care of participant registration, persistence, concurrency control and recovery.