Connection Handling in JTA and Local Transactions 

Use

The enlistment of connections in transactions depends on their transaction support. A connection may come from a connection factory with one of the following transaction support levels:

●      NoTransaction – the resource does not support transactions

●      LocalTransaction – the resource supports local transactions only

●      XATransaction – the resource supports both local and distributed transactions

The connection may also come from a factory for which you have declared a non-transactional resource reference.

In addition, the events that occur when either getConnection() is invoked on the connection factory, or connection.close()is called, depend on whether the connection is used in a JTA or a local transaction.

Features

Transactional and Non-transactional Resources

A connection is transactional – that is, it may be used in a distributed transaction if the connection factory that provided the connection is with LocalTransaction or XATransaction support and is not declared non-transactional in the deployment descriptor of the application component.

The connection cannot be used in a transaction in the following cases:

●      The connection factory is with NoTransaction support

●      You have declared a non-transactional resource reference for the factory in the SAP-specific deployment descriptor of the application component. The deployment descriptors are ejb-j2ee-engine.xml (for enterprise beans) and web-j2ee-engine.xml (for Web components).

The following example demonstrates how a resource is defined non-transactional:

<resource-ref>

  <res-ref-name>jdbc/CAR_RENTAL_POOL<res-ref-name>

  <res-link>CAR_RENTAL_POOL</res-link>

  <non-transactional/>

</resource-ref>

For example, you may use a non-transactional resource if you want to access both an SAP R/3 system and MaxDB in a single transaction. Since the connections to both back-end systems are not XA-enabled, you must declare the resource reference to one of them as non-transactional to avoid having more than one resource with LocalTransaction support enlisted in the transaction.

Using Connections in JTA Transactions

The transaction support and the sharing scope of a connection have important implications when using the resource in a JTA transaction. The following table describes the scenarios that are possible if you invoke the getConnection() method of the connection factory within the scope of a JTA transaction, and the expected system behavior in each scenario.

	LocalTransaction Support	XATransaction Support
Shareable	You get a connection in both cases. The transaction support does not change the system behavior.
Unshareable	The Java EE standard allows a single LocalTransaction resource to be enlisted in a JTA transaction. Therefore, if another resource with LocalTransaction support has already been enlisted in the transaction, you will get an exception. Otherwise, you get a connection.	You get a connection because there are no limitations to the number of XATransaction resources that may be enlisted in a JTA transaction.

We recommend that you use connection sharing as this makes transaction and resource management easier.

Closing a Connection

You must close the connections explicitly in the application code. Typically, you can use the connection in a try clause and close it in the finally block.

Connection con = cf.getConnection(); try{    ...    // Do work    ... }finally {    con.close(); }

Typically, if you invoke connection.close() on a connection used in a local transaction before its end, the transaction is rolled back and the connection is returned to the pool. For generic resource adapters, resource leaks might occur in this scenario, as Connector Container Service closes the used connections and opens new ones.