|[ Team LiB ]|
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.
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.
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();
|[ Team LiB ]|