JBossTS is based upon the original Arjuna system developed at the University of Newcastle between 1986 and 1995. Arjuna predates the OTS specification and includes many features not found in the OTS. JBossTS is a superset of the OTS. Applications written using the standard OTS interfaces are portable across OTS implementations.
JBossTS features in terms of OTS specifications
full draft 5 compliance, with support for Synchronization objects and PropagationContexts.
support for subtransactions.
implicit context propagation where support from the ORB is available.
support for multi-threaded applications.
fully distributed transaction managers, i.e., there is no central transaction manager, and the creator of a top-level transaction is responsible for its termination. Separate transaction manager support is also available, however.
transaction interposition.
X/Open compliance, including checked transactions. This checking can optionally be disabled. Note: checked transactions are disabled by default, i.e., any thread can terminate a transaction.
JDBC support.
Full JTA 1.1 support.
You can use JBossTS in three different levels, which correspond to the sections in this chapter, and are each explored in their own chapters as well.
Because of differences in ORB implementations, JBossTS uses a separate ORB Portability library which acts as an abstraction later. Many of the examples used throughout this manual use this library. Refer to the ORB Portability Manual for more details.
The OTS is only a protocol engine for driving registered resources through a two-phase commit protocol. You are
responsible for building and registering the Resource objects which handle
persistence and concurrency control, ensuring ACID properties for transactional application objects. You need to
register Resources at appropriate times, and ensure that a given
Resource is only registered within a single transaction. Programming at the raw
OTS level is extremely basic. You as the programmer are responsible for almost everything to do with
transactions, including managing persistence and concurrency control on behalf of every transactional object.
The OTS implementation of nested transactions is extremely limited, and can lead to the generation of heuristic results. An example of such a result is when a subtransaction coordinator discovers part of the way through committing that some resources cannot commit, but being unable to tell the committed resources to abort. JBossTS allows nested transactions to execute a full two-phase commit protocol, which removes the possibility that some resources will comment while others roll back.
When resources are registered with a transaction, you have no control over the order in which these resources are invoked during the commit/abort protocol. For example, if previously registered resources are replaced with newly registered resources, resources registered with a subtransaction are merged with the subtraction's parent. JBossTS provides an additional Resource subtype which you this level of control.
The OTS does not provide any Resource implementations. You are responsible for
implementing these interfaces. The interfaces defined within the OTS specification are too low-level for most
application programmers. Therefore, JBossTS includes Transactional Objects for Java
(TXOJ), which makes use of the raw Common Object Services interfaces but provides a higher-level
API for building transactional applications and frameworks. This API automates much of the activities concerned
with participating in an OTS transaction, freeing you to concentrate on application development, rather than
transactions.
The architecture of the system is shown in Figure 2. 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.
JBossTS exploits object-oriented techniques to provide you with a toolkit of Java classes which are inheritable by application classes, to obtain transactional properties. These classes form a hierarchy, illustrated in Figure 2.1, “JBossTS class hierarchy”.
Your main responsibilities are specifying the scope of transactions and setting appropriate locks within
objects. JBossTS guarantees that transactional objects will be registered with, and be driven by, the
appropriate transactions. Crash recovery mechanisms are invoked automatically in the event of failures. When
using the provided interfaces, you do not need to create or register Resource objects or
call services controlling persistence or recovery. If a transaction is nested, resources are automatically
propagated to the transaction’s parent upon commit.
The design and implementation goal of JBossTS was to provide a programming system for constructing fault-tolerant distributed applications. Three system properties were considered highly important:
| Integration of Mechanisms |
Fault-tolerant distributed systems require a variety of system functions for naming, locating and invoking operations upon objects, as well as for concurrency control, error detection and recovery from failures. These mechanisms are integrated in a way that is easy for you to use. |
| Flexibility |
Mechanisms must be flexible, permitting implementation of application-specific enhancements, such as type-specific concurrency and recovery control, using system defaults. |
| Portability |
You need to be able to run JBossTS on any ORB. |
JBossTS is implemented in Java and extensively uses the type-inheritance facilities provided by the language to provide user-defined objects with characteristics such as persistence and recoverability.
The OTS specification is written with flexibility in mind, to cope with different application requirements for transactions. JBossTS supports all optional parts of the OTS specification. In addition, if the specification allows functionality to be implemented in a variety of different ways, JBossTS supports all possible implementations.
Table 2.1. JBossTS implementation of OTS specifications
| OTS specification | JBossTS default implementation |
|---|---|
|
If the transaction service chooses to restrict the availability of the transaction context, then it
should raise the |
JBossTS does not restrict the availability of the transaction context. |
|
An implementation of the transaction service need not initialize the transaction context for every request. |
JBossTS only initializes the transaction context if the interface supported by the target object extends
the |
|
An implementation of the transaction service may restrict the ability for the
|
JBossTS does not impose restrictions on the propagation of these objects. |
|
The transaction service may restrict the termination of a transaction to the client that started it. |
JBossTS allows the termination of a transaction by any client that uses the
|
|
A |
JBossTS provides multiple ways in which the |
|
A transaction service implementation may use the Event Service to report heuristic decisions. |
JBossTS does not use the Event Service to report heuristic decisions. |
|
An implementation of the transaction service does not need to support nested transactions. |
JBossTS supports nested transactions. |
|
|
JBossTS allows |
|
A transaction service implementation is not required to support interposition. |
JBossTS supports various types of interposition. |
JBossTS is fully multi-threaded and supports the OTS notion of allowing multiple threads to be active within a
transaction, and for a thread to execute multiple transactions. A thread can only be active within a single
transaction at a time, however. By default, if a thread is created within the scope of a transaction, the new
thread is not associated with the transaction. If the thread needs to be associated with the transaction, use the
resume method of either the AtomicTransaction class or the
Current class.
However, if newly created threads need to automatically inherit the transaction context of their parent, then they
should extend the OTS_Thread class.
Example 2.1. Extending the OTS_Thread class
public class OTS_Thread extends Thread
{
public void terminate ();
public void run ();
protected OTS_Thread ();
};
Call the run method of OTS_Thread at the start of the application
thread class's run method. Call terminate before you exit the
body of the application thread’s run method.
Although the CORBA specification is a standard, it is written so that an ORB can be implemented in multiple ways. As such, writing portable client and server code can be difficult. Because JBossTS has been ported to most of the widely available ORBs, it includes a series of ORB Portability classes and macros. If you write your application using these classes, it should be mostly portable between different ORBs. These classes are described in the separate ORB Portability Manual.