What is JBossJTS?
A set of JBoss modules that fully supports ACID transactions spread across multiple resource managers and application servers. It implements a Distributed Transaction Manager (DTM) with support for two-phase commit (2PC) across XA resource managers, JBoss server instances, and CORBA OTS resources. JBossJTS builds upon our previous TransactionRecovery prototype, which handled crash recovery for transactional work across XA resource managers, and extends it to perform recovery also in the case of transactional work across application servers. Those application servers may be either JBoss server instances or non-JBoss servers with CORBA OTS support.
JBossJTS implements the Java Transaction Service (JTS) and CORBA Transaction Service (OTS) specifications.
Specification Summary
A DTM instance runs within a JBoss server instance and knows two general kinds of transactional resources:
XA resources, which represent resource managers (DBMSs, MOM systems, etc.) accessible to the JBoss server instance through JCA resource adapters with XA support, such as XA-enabled JDBC drivers and JMS providers;
Remote resources, which represent systems directly or indirectly accessible to the JBoss server instance through a remote method invocation mechanism. Other J2EE application servers instances and CORBA servers in general are examples of systems that may receive direct or indirect calls from a JBoss server instance.
A DTM instance acts as transaction coordinator and drive the 2PC protocol for these two kinds of resources. The DTM instance interacts with its XA resources through the standard XA API. It interacts with remote resources either via standard OTS interfaces or via JBoss-specific interfaces (see below).
Crash recovery is supported. To be able to recover from system crashes, a DTM instance performs write-ahead logging (WAL) of the relevant 2PC events.
In the case of a remote resource, the DTM supports two remote method invocation mechanisms:
CORBA/IIOP, with remote invocations being performed using either the RMI programing model (RMI/IIOP) or the IDL-based CORBA model.
JBoss remoting, with remote invocations being performed over any of the protocols supported by the JBoss Remoting framework.
Accordingly, remote resources may be either CORBA resources or JBoss remoting resources.
The DTM implicitly propagates the transactional context in remote invocations to other JBoss server instances and to OTS-compliant application servers or CORBA servers.
In CORBA/IIOP invocations, the transaction context is propagated in the standard format defined by the OTS specification. 2PC interactions between a DTM instance and remote CORBA resources take place throught the standard interfaces defined by OTS. This ensures interoperability with other OTS-compliant application servers and with transactional CORBA servers in general.
In JBoss remoting invocations, the transaction context is propagated in a JBoss-specific format. 2PC interactions between a DTM instance and remote CORBA resources take place throught JBoss-specific interfaces, which were patterned after the corresponding OTS interfaces.
Transactional invocations between JBoss server instances may be performed either via CORBA/IIOP or JBoss remoting. Transactional invocations to/from non-JBoss servers must be made via CORBA/IIOP. Both remote invocation mechanisms are available to Java clients.
A DTM instance accepts foreign transaction contexts received along with remote invocations. Such a transaction context contains a remote reference to a parent coordinator, which may or may not be located in another JBoss server instance. If the parent coordinator is not contained in a JBoss server instance, then it must be a CosTransactions::Coordinator object implemented by an OTS-compliant transaction service.
A method invocation performed in a foreign transaction context may or may not use XA resources of the target application server.
If it uses one or more XA resources, then the target DTM registers itself as a remote resource with the parent coordinator. At transaction commit time the target DTM acts as a sub-coordinator for the XA resources of the target application server.
If it uses no XA resources, then the target DTM may or may not perform interposition, depending on its configuration. Interposition is supported but not mandated by the OTS specification. It means that the target DTM registers itself as a resource with the parent coordinator and interposes itself as a sub-coordinator in the transactional context propagated along with outgoing invocations. No interposition means that the target DTM does not register itself as a resource with the parent coordinator. Instead, it passes that parent coordinator in the transactional context propagated along with outgoing invocations.
Related
Comments