Overview

The XA specification and its Java version (JTA) introduce a standard way to control and manage distributed transactions among different participants. The JTA defines two major entities from our point of view: the Transaction Manager and XAResource. The Transaction Manager acts as a transaction coordinator and responds to the transaction context (start, end, suspend and resume) and its completion using a 2PC protocol. The XAResource represents the resource manager and responds to answers from 2PC commands sent by the Transaction Manager.

XA transactions should generally be avoided and not used. The overhead of managing a 2PC transaction over two or more resources is often times a performance killer. We recommend using well-known patterns in order to avoid it (such as duplicate detection).

GigaSpaces XA transactions can not span over different spaces in the same cluster. For example, writing an object to Member1 under a transaction, and then writing another object to Member2 under the same transaction, does not work. In order to make this work, make sure that you write the object to the same cluster member (e.g. using SpaceRouting).

When attempting to roll back a non-existing transaction or a transaction the has already been rolled back, an exception is thrown. For more details, see com.gs.xa.failOnInvalidRollback.

Transaction Sequence

The typical transaction sequence should look like this:

When the T.M. starts or recovers, it should call recover() on all the known XAResources, which should return all the prepared transaction XIDs.

XA vs. Jini Transaction

The XA API (JTA) differs from the Jini Transaction API in two major respects:

• The Jini transaction API only manages distributed transactions among participants that are Jini services while the XA API allows for the ability to manage distributed transactions among all kinds of resource adapters, as long as they implement the XAResource interface.
• The Jini Transaction sequence differs from the XA in one major respect, which is that there is no enlistment stage. Instead, the participants are responsible for joining the transaction by calling join() on the Transaction Manager.

Using XA Global Transactions without JCA

GigaSpaces can participate in global (XA) transactions, even when it is not connected with JCA.

Involving the space in XA transactions requires the following:

1. Creating a XAResource for the space.
2. Enlisting the XAResource to the transaction when the transacted EJB method executes.

Involving Space with Global Transactions without JCA

The code example below is run in the WebLogic AppServer, but it can be modified to work with other vendors as well.

To create the XAResource, do as follows:

LocalTransactionManager gigaspacesTM = LocalTransactionManager)LocalTransactionManager.getInstance(spaceInstance);
xaRes = new XAResourceImpl(gigaspacesTM, (ActionMaker)spaceInstance);

In the transacted EJB method, you enlist the XAResource to the current transaction:

javax.transaction.Transaction txn = weblogic.transaction.TransactionHelper.getTransactionHelper().getTransaction();
txn.enlistResource(xaRes);

Example

The ReplicatedSessionBean example write() method can be run in a global transaction. To test it:

1. Uncomment the comments in the code that initialize and enlist the XAResource.
2. Build the example.
3. Compile the example by updating the setExampleEnv.bat/sh file in the <GigaSpaces Root>\j2ee\examples directory, and specify the home directory of your WebLogic installation.
4. Finally, deploy the bean and test it.

In the current code, only the write() method is involves the space in a global transaction.