Implementing transaction support

A transaction is an isolated interaction with the EIS. Transaction support allows users to ensure that multiple operations on the EIS are performed as atomic units and are not impacted by other simultaneously occurring operations from other EIS clients.

Note: Transactions can be supported in an adapter only if the underlying EIS supports transactions.

EIS application transactions typically rely on one of two commit protocols: the one-phase or two phase commit protocols. The one-phase commit protocol allows a client to demarcate the beginning and end of transactional operations with a single EIS application. The two-phase commit protocol, which is a superset of the one-phase protocol, enables transactions to span multiple, heterogeneous EIS systems. So, applications that support the one-phase commit protocol are often said to support local transactions while those that support the two-phase commit protocol are said to support global, or XA, transactions.

While an adapter can expose support for either or both protocols, the underlying EIS must ultimately provide the support. By this token, you would not attempt to implement XA support in your adapter if your underlying EIS application inherently lacked transaction support.

Once you have determined that your EIS supports transactions, you must make several modifications to your adapter to implement the support.

Update Your Adapter Deployment Descriptor Property TransactionSupport, as described in the JCA 1.5 specification, supports three values: NoTransaction, LocalTransaction, and XATransaction. You must specify the appropriate value for the level of support you intend to provide. If your adapter supports XA, specify XATransaction support but also implement the local transaction features described below. (The JCA specification prescribes that any adapter supporting XA should also support local transactions.)
Update your adapter-specific construction of WBIResourceAdapterMetadata to reflect support for local transactions. ResourceAdapterMetadata#supportsLocalTransactionDemarcation should return true.
Override method WBIManagedConnection.getLocalTransaction() and, if XA support is provided, method WBIManagedConnection.getXAResource().

Wrap either or both of the LocalTransaction or XAResource instances returned by these methods with a WBILocalTransactionWrapper or WBIXATransacxtionWrapper instance. These wrappers provide extended diagnostics for troubleshooting and also help adapters determine whether or not to autocommit requests. According to the JCA 1.5 specification, a resource adapter must autocommit transactions when being used outside the context of a transaction. To help the managed connection determine if it is involved in a transaction, these wrappers act as thin delegation layers, monitoring the sequence of calls to determine whether a transaction is active. At the beginning of a transaction, the wrappers call method setEnlistedInATransaction(true) on the WBIManagedConnection instance; upon commit or rollback, the wrappers set this same property to false. By then checking the status of the transaction via method isEnlistedInTransaction on the super class, a WBIResourceAdapter subclass can quickly determine whether it should be automatically committing transactions or not when modifying the EIS.

Note: When overriding methods, do not invoke the super implementations of these methods since the Adapter Foundation Classes simply throw exceptions for these methods.

Example of an XA-enabled adapter implementation of WBIManagedConnection

public class <AdapterPrefixName>ManagedConnection extends WBIManagedConnection
{
// just get the XAResource from your EIS and return the wrapper 
                             public XAResource getXAResource() {
XAResource eisXAResource = this.eisXAConnection.getXAResource();
XAResource wrapper = new WBIXATransactionWrapper(eisXAResource,this);
return wrapper;
		}	

		// here's an example of a potentially transacted call on the EIS. Point
		// is that adapter should always check whether it's enlisted in a 
		// container-managed transaction or whether it should handle transaction
		// on its own
		private void updateRecord(int id,int value) {
	if(!this.isEnlistedInTransaction())
		this.eisConnection.beginTransaction();

	eisConnection.updateRecord(id,value);
		
	if(!this.isEnlistedInTransaction())
		this.eisConnection.commitTransaction();
	}
}