9.2. JBoss Transaction Service

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, such as concurrency control and state management, need to be inherited. Others, such as object storage and transactions, are implemented as JBoss Transaction Service objects that are created and manipulated like any other object.


When using persistence and concurrency control facilities, it is assumed that the Transactional Objects for Java (TXOJ) classes are being used. Other mechanisms are not discussed here.
JBoss Transaction Service uses object-oriented techniques to present programmers with a toolkit of Java classes 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 below and which will be described later in this document.
JBoss Transaction Service Class Hierarchy

Figure 9.1. JBoss Transaction Service Class Hierarchy

The programmer is only responsible for specifying the scopes of transactions and setting appropriate locks within objects. JBoss Transaction Service and Transactional Objects for Java (TXOJ) ensure registration and function with the appropriate transactions, as well as crash recovery in the case of failure.

9.2.1. Saving Object States

JBoss Transaction Service remembers the state of an object. It needs this information for recovery , in which the state represents some past state of the object, and persistence, in which the state represents the final state of an object at application termination. All of these requirements are implemented using the same mechanism: the InputObjectState class and the OutputObjectState class. The classes maintain an internal array into which instances of the standard types can be contiguously packed and unpacked using pack and unpack operations. This buffer is automatically resized as required. The instances are all stored in the buffer in a standard machine-independent form called network byte order. Any other architecture-independent format, such as XDR or ASN.1), can be implemented by replacing the classes with the ones corresponding to the pack and unpack function in the required format.