Transaction Management

The capability to handle transactions is a key component in the J2EE Connector Architecture. Transaction management allows different operations to be performed independently, but the transactions are either all committed or all rolled back, keeping the integrity of the transaction intact. Database operations have incorporated this feature for many years, but the capability to allow transactions with EIS systems is a significant step in building applications that incorporate multiple systems. Unfortunately, not every resource adapter will support full two-phase commit protocol transactions. Each resource adapter specifies the level of transaction support available.

Transaction Support

WebLogic 8.1 incorporates three different transaction support levels based on the J2EE-CA 1.0 specification. In the section "Configuring Resource Adapters" later in this chapter, you'll see where to define these in the ra.xml file.

• None— No transaction support exists.

• Local support— Local support allows the resource adapter to manage its own transactions. This support level does not allow participation in two-phase commit protocol and is not compatible with any JTA/JTS transactions.

• XA support— XA support includes local support and is able to manage the transaction external to the resource adapter. This means that the resource adapter supports either one- or two-phase commit protocol and can take place in larger JTA/JTS transactions that require data integrity.

No Transaction Support

If a resource adapter does not support transactions, it cannot use any connections to the EIS in a transaction. If an application uses a resource adapter that doesn't support transactions and it needs to use a connection in a transaction, it has to interact through another resource manager that does contain transaction support.

Local Transaction Support

Local transactions are limited to the container. They can be managed locally by the resource adapter or by the container. However, they cannot take part in any two-phase transactions, including JTA/JTS. When an application component such as an EJB wants to connect to the EIS system, the application server starts a local transaction. When the component closes the connection, the application server performs a commit on the local transaction followed by a cleanup of the EIS connection. Local transactions use one-phase commit protocols or the interpretation of them based on the EIS implementation. To use local transactions when connecting to a resource adapter, simply get your transaction from a JNDI lookup, begin the transaction, and then either commit or roll it back. Here's an example:

Connection connection = null;
InitialContext initialcontext = new InitialContext();
ConnectionFactory connectionfactory =
            initialcontext.lookup("java:comp/YourConnectionFactory");
UserTransaction userTransaction =
(UserTransaction) initialcontext.lookup("java:comp/UserTransaction");
// start userTransaction
userTransaction.begin();
connection = connectionfactory.getConnection();
// do some work
// commit transaction
userTransaction.commit();

XA Transaction Support

XA transactions are managed externally to the resource adapter. If XA transactions are supported, the resource adapter must support both one- and two-phase commit protocols (one-phase commits are used for optimization purposes). When an application component makes a request to an EIS system, the application server lists the connection to the EIS system within the transaction manager. The entire transaction is maintained for the duration until it is committed or rolled back. If the connection is closed by the application component, the application server then unlists the EIS connection from the transaction and cleans up the underlying EIS connection. The resource adapter contains any of the proprietary needs of the EIS system and adheres to the J2EE Connector Architecture specification for XA transactions to implement the two-phase commit protocol.

If two-phase commits are allowed, the resource adapter and underlying resource manager must be JTA/JTS compliant and correctly implement the XAResource interface.

If the entire operation is contained within one resource manager, the application server can optimize the transaction by using a local transaction instead of a JTA/JTS transaction for performance reasons. To implement a XA transaction, the resource adapter must be XA transaction compliant. The code for demarcating the XA transaction looks exactly like that of the local transaction except for one detail: Two resource adapters are being called within one transaction instead of one. The transaction manager takes care of rolling back both transactions if they fail. In fact, the programmer does not even have access to the XA transaction objects. They're completely contained within the resource adapter. This includes any exceptions that are thrown along the way.

       Connection connection1 = null;
       Connection connection2 = null;
InitialContext initialcontext = new InitialContext();
       ConnectionFactory connectionfactory1 =
        initialcontext.lookup("java:comp/YourConnectionFactory1");
        ConnectionFactory connectionfactory2 =
        initialcontext.lookup("java:comp/YourConnectionFactory2");
       UserTransaction userTransaction =
      (UserTransaction) initialcontext.lookup("java:comp/UserTransaction");
        // start userTransaction
        userTransaction.begin();
        connection1 = connectionfactory1.getConnection();
        connection2 = connectionfactory2.getConnection();
       // do some work
       // commit transaction
        userTransaction.commit();