Pp. 89–100 of the Proceedings

Abstract

1. Introduction

Atomic transactions are a well-known technique for guaranteeing application consistency in the presence of failures. Web applications already exist which offer transactional guarantees to users. However, currently these guarantees only extend to resources used at Web servers, or between servers; clients (browsers) are not included, despite their role being significant in applications such as mentioned previously. Providing end-to-end transactional integrity between the browser and the application is important: in the previous example, the cookie must be delivered once the user's account has been debited. Cgi-scripts cannot provide this level of transactional integrity since replies sent after the transactions have completed may be lost, and replies sent during the transaction may need to be revoked if the transaction cannot complete. This is an inherent problem with the original "thin" client model of the Web, where browsers were functionally barren. With the advent of Java it is now possible to consider empowering browsers so that they can fully participate within transactional applications. However, to be widely applicable, we claim that any such transaction system must meet the following three requirements:

(i) it must support distributed, nested transactions;

(ii) it must not compromise the security policy imposed at the browser's site; and,

(iii) it must comply with appropriate standards.

We have designed and implemented the JTSArjuna system, a transaction toolkit that meets the above requirements. Our toolkit allows transactional applications to span Web browsers and servers and supports application specific customisation, so that an application can be made transactional without compromising the security policies operational at browsers and servers. The toolkit complies with the OMG Object Transaction Service (OTS) and the Java Transaction Service (JTS) standards [OMG95][VM96]. Although the OMG has specified several object services, there is no specification for an overall object model with which to glue them together into a coherent application development framework. Therefore, we have provided a high-level API which allows programmers to be isolated from many of the issues involved in building transactional applications. This API is the result of extensive experience with the original C++ Arjuna distributed transaction system [GDP95][SKS95].

2. Transaction standards for distributed objects

2.1 The Object Transaction Service

The transaction service specification distinguishes between recoverable objects and transactional objects. Recoverable objects are those that contain the actual state that may be changed by a transaction and must therefore be informed when the transaction commits or aborts to ensure the consistency of the state changes. This is achieved be registering appropriate objects that support the Resource interface (or the derived SubtransactionsAwareResource interface) with the current transaction. In contrast, a simple transactional object need not necessarily be a recoverable object if its state is actually implemented using other recoverable objects. The major difference is that a simple transactional object need not take part in the commit protocol used to determine the outcome of the transaction since it does not maintain any state itself, having delegated that responsibility to other recoverable objects which will take part in the commit process.

It is important to realise that the OTS is simply a protocol engine that guarantees that transactional behaviour is obeyed but does not directly support all of the transaction properties. As such it requires other co-operating services that implement the required functionality, including:

• Persistence/Recovery Service. Required to support the atomicity and durability properties. (There is no recovery service currently specified by the OMG.)
• Concurrency Control Service. Required to support the isolation properties.

2.2 Writing OTS applications

• creating Resource and SubtransactionAwareResource objects for each object which will participate within the transaction/subtransaction. These resources are responsible for the persistence, concurrency control, and recovery for the object. The OTS will invoke these objects during the prepare/commit/abort phase of the (sub)transaction, and the Resources must then perform all appropriate work.
• registering Resource and SubtransactionAwareResource objects at the correct time within the transaction, and ensuring that the object is only registered once within a given transaction. As part of registration a Resource will receive a reference to a RecoveryCoordinator which must be made persistent so that recovery can occur in the event of a failure.
• ensuring that, in the case of nested transactions, any propagation of resources such as locks to parent transactions are correctly performed. Propagation of SubtransactionAwareResource objects to parents must also be managed.
• in the event of failures, the programmer or system administrator is responsible for driving the crash recovery for each Resource which was participating within the transaction.

The architecture of the system is shown in figure 1. As we shall show, the API interacts with the concurrency control and persistence services, and automatically registers appropriate resources for transactional objects. These resources may also use the persistence and concurrency services.

Figure 1: JTSArjuna structure

3. Requirements for configuration

The constraints imposed by SecurityManagers can directly affect transactional applications which may require, for example, to make state updates persistent by accessing the local disk. There are two obvious solutions to this problem: (i) all objects must reside within domains which have well-behaved security constraints (Web servers), or (ii) modify the Java language and the interpreter and provide an implementation of the SecurityManager which relaxes these security restrictions [MA96]. The first solution is unnecessarily restrictive in environments where SecurityManagers do allow programs increased flexibility. The second solution lacks portability as it requires users to have access to specialised implementations.

Our solution was to design and implement the JavaGandiva configuration support framework based on the model described in [SMW96], which isolates applications and programmers from the differences between Java SecurityManagers. Applications can be dynamically configured to take advantage of the environment in which they execute. As we shall show, several JTSArjuna classes must use this framework to provide portability across SecurityManagers.

3.1 Configuration model

3.2 JavaGandiva implementation

In order to leave this binding until run-time we must specify it as data and not within the code of the interface class. The instance of the interface class (interface object) uses this data to create and bind to the correct instance of the implementation class (implementation object). To provide this separation of interface component and implementation component requires changing what would have been a single Java class into three classes, and a Java interface:

1. the interface class: users interact with instances of this class, which defines the public operations that can be invoked on the implementation. The only implementation specific information present in the class definition is a reference to an instance of an implementation interface, to which the interface delegates all operations.
2. the implementation interface: this is a Java interface and all implementations accessible to an interface class implement it. This guarantees that all implementations conform to a known type.
2. the implementation class: instances of this class represent the implementation of an object. Implementation classes can be derived from multiple implementation interfaces.
3. the control class: this class provides access to operations that manipulate the non-functional characteristics of an implementation class. Implementation classes provide an operation that returns a specific instance of this control class. Interface classes provide an operation that can be used to request an instance of the implementation's control class.

3.3 JavaGandiva built-time support

To incorporate configurability into an application, the programmer creates a Configuration Management Object (CMO). The CMO contains data which specifies the interface to implementation bindings for the application, and any data required by implementations for initialisation. The data may also specify alternate implementations, e.g., because of possible security restrictions. At bind time an interface interrogates the CMO to determine which implementation it requires, and then passes this information to the run-time system. Importantly for our purposes, the CMO data associated with an application can be specified at run time, therefore providing a way to configure the application for each user and environment.

3.4 JavaGandiva run-time support

Figure 3 illustrates how an interface uses these objects when binding to an appropriate implementation. When an interface requires to be bound to an implementation, it interrogates the application CMO for the implementation type. It then requests an instance of this type from the repository. If the requested implementation type does not exist, or cannot be used within the current environment, then the binding will fail. The interface can then attempt an alternate binding if one is specified by the CMO. Importantly, none of this is visible to the application, which simply attempts to create and use an object.

Figure 3: Application execution environment.

3.5 Specifying an application's configuration

The (simplified) signature of ObjectName, without the exceptions it can throw, is shown below:
 

public class ObjectName implements Serializable 
{ 
// the supported attribute types 
public static final int SIGNED_NUMBER = 0;

// for C++ compatibility 
public static final int UNSIGNED_NUMBER = 1; 
public static final int STRING = 2; 
public static final int OBJECTNAME = 3; 
public static final int CLASSNAME = 4; 
public static final int UID = 5; 

public int attributeType (String attrName);
public String firstAttributeName (); 
public String nextAttributeName (String curr);

/* 
 * Now a series of set/get methods for each 
 * type of attribute. We show only two for 
 * simplicity. 
 */ 

public long getLongAttribute (String atr); 
public String getStringAttribute (String atr);

public void setLongAttribute (String atr, long value); 
public void setStringAttribute (String atr, String value);

public boolean removeAttribute (String atr); 
public boolean equals (ObjectName objectName); 
public boolean notEquals (ObjectName objName);

// how to store/retrieve data

private NameService _nameService; 
}

To enable the configuration information to be stored in a flexible manner, ObjectName stores and retrieves the information using a separate NameService interface and implementation. Therefore, the means of storing this configuration data can be changed simply be changing the NameService implementation. For example, the JDBC (Java Database Connectivity) API is a standard SQL database access interface, providing uniform access to a wide range of relational databases. By providing a suitable NameService implementation, the ObjectName data could be maintained within such a database. However, to minimise external dependencies, our current implementation for Web applications embeds the ObjectName data within the HTML document which is downloaded with the Java application. The HTML document is created automatically from a separate description language.

3.6 Implementation repository

1. statically at build time: each implementation can be registered with the inventory when the application is built, i.e., a specific inventory is constructed for each application. If implementations are required to be added or removed from the inventory then the inventory implementation must be modified.
2. dynamically at run time: implementations may be loaded across the network or from the local disk. Given the name of a class, an inventory can attempt to load it dynamically. This has the advantage of flexibility, but requires the sources of these implementations (e.g., Web servers) to remain available while the application is being configured.

The Inventory interface class has methods for obtaining an instance of an implementation from its class name. For simplicity we show only a representative set of these methods, without the exceptions they throw:

public class Inventory 
{ 
public synchronized Object createVoid (String typeName); 
public synchronized Object createObjectName (String typeName, ObjectName paramObjectName); 
public synchronized Object createResources (String typeName, Object[] paramResources);

/* 
 * A handle on the application's inventory 
 * for bootstrapping (already bound interface 
 * and implementation. 
 */

public static Inventory inventory (); 
}

3.7 Determining security restrictions

To determine whether or not it can function within the security environment, the implementation object may extract information from the ObjectName it is given when it is created, e.g., the location of the object store database to use. Shown below is the canExecute method for a simple object store service which writes to the local file system:

public SimpleObjectStore implements ObjectStoreImple 
{ 
public boolean canExecute () 
{ 
  /* 
   * First get handle on current 
   * SecurityManager. 
   */

  SecurityManager manager = System.getSecurityManager();

  if (manager == null) 
    return true; // no restrictions! 
  else 
  { 
    /* 
     * There is a SecurityManager, so 
     * interrogate it. 
     */

     try 
     { 
       /* 
        * Assume these file names were read 
        * from the ObjectName when we were 
        * created. 
        */

       manager.checkRead("/ObjStore/data"); 
       manager.checkWrite("/ObjStore/data); 
       manager.checkDelete("/ObjStore/data");

       return true; 
     } 
     catch (Exception e) 
     { 
       /* 
        * SecurityManager raised an 
        * exception, could try alternate 
        * location. 
        */

       return false; 
     } 
  } 
} 
}

4. JTSArjuna implementation

Figure 4: JTSArjuna class hierarchy

As we shall show, apart from specifying the scopes of transactions, and setting appropriate locks within objects, the application programmer does not have any other responsibilities: JTSArjuna guarantees that transactional objects will be registered with, and be driven by, the appropriate transactions, and crash recovery mechanisms are invoked automatically in the event of failures.

4.1 Saving object states

4.2 The object store

Persistent objects are assigned unique identifiers (instances of the Uid class), when the are created, and this is used to identify them within the object store. States are read using the read_committed operation and written by the write_(un)committed operations.

public interface ObjectStoreImple 
{ 
public boolean commit_state (Uid id); 
public InputObjectState read_committed (Uid id); 
public InputObjectState read_uncommitted (Uid id); 
public boolean remove_committed (Uid id); 
public boolean remove_uncommitted (Uid id); 
public boolean write_committed (Uid id, OutputObjectState state); 
public boolean write_uncommitted (Uid id, OutputObjectState state); 
};

4.3 Recovery and persistence

public abstract class StateManager 
{ 
public boolean activate (); 
public boolean deactivate (boolean commit);

public Uid get_uid (); // object's identifier.

// methods to be provided by a derived class

public abstract boolean restore_state (InputObjectState os); 
public abstract boolean save_state (OutputObjectState os);

protected StateManager (); 
protected StateManager (Uid id); 
};

If an object is recoverable (or persistent) then StateManager will invoke 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. (We are examining the automatic generation of default save_state and restore_state operations, allowing the programmer to override this when application specific knowledge can be used to improve efficiency.) 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 could simply be:

public boolean save_state(OutputObjectState o) 
{ 
  return (o.packInt(A) && o.packInt(B) && o.packInt(C)); 
}

4.4 The concurrency controller

• local disk/database implementation, where locks are made persistent by being written to the local file system or database.
• a purely local implementation, where locks are maintained within the memory of the virtual machine which created them; this implementation has better performance than when writing locks to the local disk, but objects cannot be shared between virtual machines. Importantly, it is a basic Java object with no requirements which can be affected by the SecurityManager.

public abstract class LockManager extends StateManager 
{ 
public LockResult setlock (Lock toSet, int retry, int timeout); 
};

The code below shows how we may 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) == Lock.GRANTED)
  { 
    /* 
     * Do some work, and JTSArjuna will 
     * guarantee ACID properties.
     */

    // automatically aborts if fails

    if (A.commit() == AtomicAction.COMMITTED)
    {
      result = true; 
    }
  }
  else
    A.rollback();

  return result;
} 
}

4.5 Configuration hierarchy

5. Performance results

These figures represent the initial implementation of our Java transactions. Based upon our experiences with JTSArjuna and its C++ counterpart, we believe that further optimisations to the system are possible which will improve performance.

6. Newspaper example using JTSArjuna

The entities involved in the newspaper application are:

• the user's on-line bank, from where funds will be debited. We shall assume that the newspaper's account is also located here.
• the newspaper site, where the user's details will be added upon successfully completing the transaction.
• the user's browser site, where a cookie authenticating the user must be delivered and stored.

Figure 6: Transactional newspaper.

We first use the transactional toolkit to construct the application classes and partition the application as shown. An example of the cookie class which resides within the browser is:

public class Cookie extends LockManager
{ 
public Cookie ();

public boolean depositCookie (UserDetails obj)
{ 
  AtomicAction B = new AtomicAction(); 
  boolean result = false; 

  B.begin (); // start transaction 
              // automatically nested if one
              // is already running

  if (setlock(new Lock(LockMode.WRITE) == Lock.GRANTED)
  {
    userDetails = obj;

    if (B.commit()) // aborts if cannot commit
      result = true;
  }
  else
    B.abort();

  return result;
};

public boolean save_state (OutputObjectState os);
public boolean restore_state (InputObjectState os);

private UserDetails userDetails;
};

{
  AtomicAction A = new AtomicAction();
  BankAccount B1 = new BankAccount(UserNumb);
  BankAccount B2 = new BankAccount(PaperNumb);
  Cookie C = new Cookie();

  A.begin();

  if (B1.debit(amount) && B2.credit(amount))
  {
    if (C.depositCookie(UserDetails))
      A.commit();
    else
      A.abort();
  }
  else
    A.abort();
}

Obviously we would like to store the cookie on the user's local disk. However, security restrictions imposed by the browser's SecurityManager (or by the user if digital signatures are being used) may prevent this. Thus, we require an alternate form of persistence in these situations. In this example we shall assume that the newspaper site will provide a persistence service implementation which is available remotely should the local implementation fail.

After identifying the application configuration, we can construct the HTML document containing the configuration information which will be downloaded with the Java application. (The '~' and '!' characters preceding each attribute value are used for runtime type checking by ObjectName.) Importantly, there are no requirements from the application user: all implementations will be loaded across the network when required.

<HTML>
<HEAD><TITLE>Example Applet</TITLE></HEAD>
<BODY>
<APPLET CODE=TranApplet.class WIDTH=400 HEIGHT=200>
<PARAM NAME=OSClassName1 VALUE="~LocalObjectStoreImple">
<PARAM NAME=OSLocation1 VALUE="!/tmp/ObjectStore">
<PARAM NAME=OSClassName2 VALUE="~RemoteObjectStoreImple">
<PARAM NAME=OSLocation2 VALUE="!glororan.ncl.ac.uk">
<PARAM NAME=CCClassName1 VALUE="~LocalCCImple">
</APPLET>
</BODY>
</HTML>

The preferred type of the persistence service is LocalObjectStoreImple, with the attribute name OSClassName, and the location of the object store is the directory /tmp/ObjectStore. If this fails, the interface can use the alternate implementation RemoteObjectStoreImple which is on the specified machine. The concurrency service is local. If the programmer wishes to change the configuration of the application, only modifications to the HTML document are required.

7. Comparisons with other systems

7.1 Transactions through cgi-scripts

In a failure free environment, this mechanism works well, with atomic actions guaranteeing the consistency of the server application. However, in the presence of failures it is possible for message 2 to be lost between the server and the browser. If the transaction commits, the reply will be sent after the transaction has ended; therefore, other work performed within the transaction will have been made permanent. For some applications this may not be a problem, e.g., where the result is simply confirmation that the operation has been performed. If the result is a cookie, however, the loss of the cookie will leave the user without his purchase and money, and may require the service provider to perform complex procedures to verify the cookie was lost, invalidate it and issue another.

Figure 7: transactions through cgi-scripts

7.2 Transactions in persistent Java

1. They require changes to the Java interpreter and language. Applications written using these systems will only execute on specialised interpreters.
2. Both schemes assume that the entire application will be written in Java, and will not be distributed, i.e., it will either execute at the browser or at the Web server.

8. Concluding remarks

Acknowledgements

References

[GDP95]"The Design and Implementation of Arjuna", G.D. Parrington et al, USENIX Computing Systems Journal, Vol. 8., No. 3, Summer 1995, pp. 253-306.

[JSF95] J. S. Fritzinger and M. Mueller, "Java Security", Sun Microsystems, 1995.

[MA96] "Draft Pjava Design 1.2", M. Atkinson et al, Department of Computing Science, University of Glasgow, January 1996.

[MCL97] M. C. Little and S. K. Shrivastava, "Distributed Transactions in Java", Proceedings of the 7^th International Workshop on High Performance Transaction Systems, September 1997, pp. 151-155.

[OMG95] "CORBAservices: Common Object Services Specification", OMG Document Number 95-3-31, March 1995.

[SKS95] S. K. Shrivastava, "Lessons learned from building and using the Arjuna distributed programming system," International Workshop on Distributed Computing Systems: Theory meets Practice, Dagsthul, September 1994, LNCS 938, Springer-Verlag, July 1995.

[SMW96] "The Design and Implementation of a Framework for Configurable Software", S. M. Wheater and M. C. Little, Proceedings of the 3^rd International Workshop on Configurable Distributed Systems, May 1996, pp. 136-143.

[TRA96] "Transarc DE-Light Web Client Technical Description", Transarc Corporation, February 1996.

[VM96] "JTS: A Java Transaction Service API", V. Matena and R. Cattell, Sun Microsystems, December 1996.

Availability