Use local transactions: WAS v5.1

Use local transactions

Local transaction containment (LTC) support, and its configuration through local transaction extended deployment descriptors, gives IBM WebSphere Application Server application programmers a number of advantages. This topic describes those advantages and how they relate to the settings of the local transaction extended deployment descriptors. This topic also describes points to consider to help you best configure transaction support for some example scenarios that use local transactions.

Develop an enterprise bean or servlet that accesses one or more databases that are independent and require no coordination. If an enterprise bean does not need to use global transactions, it is often more efficient to deploy the bean with the Container Transaction deployment descriptor Transaction attribute set to Not supported instead of Required.
With the extended local transaction support of IBM WAS, applications can perform the same business logic in an unspecific transaction context as they can under a global transaction. An enterprise bean, for example, runs under an unspecified transaction context if it is deployed with a Transaction attribute of Not supported or Never.
The extended local transaction support provides a container-managed, implicit local transaction boundary within which application updates can be committed and their connections cleaned up by the container. Applications can then be designed with a greater degree of independence from deployment concerns. This makes using a Transaction attribute of Supports much simpler, for example, when the business logic may be called either with or without a global transaction context.
An application can follow a get-use-close pattern of connection usage regardless of whether or not the application runs under a transaction. The application can depend on the close behaving in the same way and not causing a rollback to occur on the connection if there is no global transaction.
There are many scenarios where ACID coordination of multiple resource managers is not needed. In such scenarios running business logic under a Transaction policy of Not supported performs better than if it had been run under a Required policy. This benefit is exploited through the Local Transactions - Resolution-control extended deployment setting of ContainerAtBoundary. With this setting, application interactions with resource providers (such as databases) are managed within implicit RMLTs that are both started and ended by the container. The RMLTs are committed by the container at the configured Local Transactions - Boundary; for example at the end of a method. If the application returns control to the container by an exception, the container rolls back any RMLTs that it has started.
This usage applies to both servlets and enterprise beans.

Use local transactions in a managed environment that guarantees clean-up. Applications that want to control RMLTs, by starting and ending them explicitly, can use the default Local Transactions - Resolution-control extended deployment setting of Application. In this case, the container ensures connection cleanup at the boundary of the local transaction context.
J2EE specifications that describe application use of local transactions do so in the manner provided by the default setting of Local Transactions - Resolution-control=Application and Local Transactions - Unresolved-action=Rollback. By configuring the Local Transactions - Unresolved-action extended deployment setting to Commit, then any RMLTs started by the application but not completed when the local transaction containment ends (for example, when the method ends) are committed by the container. This usage applies to both servlets and enterprise beans.

Extend the duration of a local transaction beyond the duration of an EJB component method. The J2EE specifications restrict the use of RMLTs to single EJB methods. This restriction is because the specifications have no scoping device, beyond a container-imposed method boundary, to which an RMLT can be extended. In WBI Server Foundation, you can exploit the Local Transactions - Boundary extended deployment setting to give the following advantages...

Significantly extend the use-cases of RMLTs
Make conversational interactions with one-phase resource managers possible through ActivitySession support.

An ActivitySession is a WBI Server Foundation programming model extension that provides a distributed context with a boundary that is longer than a single method. You can extend the use of RMLTs over the longer ActivitySession boundary, which can be controlled by a client. The ActivitySession boundary reduces the need to use distributed transactions where ACID operations on multiple resources are not needed. This benefit is exploited through the Local Transactions - Boundary extended deployment setting of ActivitySession. Such extended RMLTs can remain under the control of the application or be managed by the container depending on the use of the Local Transactions - Resolution-control deployment descriptor setting.

Coordinate multiple one-phase resource managers. For resource managers that do not support XA transaction coordination, a client can exploit ActivitySession-bounded local transaction contexts. Such contexts give a client the same ability to control the completion direction of the resource updates by the resource managers as the client has for transactional resource managers. A client can start an ActivitySession and call its entity beans under that context. Those beans can perform their RMLTs within the scope of that ActivitySession and return without completing the RMLTs. The client can later complete the ActivitySession in a commit or rollback direction and cause the container to drive the ActivitySession-bounded RMLTs in that coordinated direction.

To determine how best to configure the transaction support for an application, depending on what you want to do with transactions, consider the following points.

General points

You want to start and end global transactions explicitly in the application (BMT session beans and servlets only).
For a session bean, set the Transaction type to Bean (to use bean-managed transactions) in the component's deployment descriptor. (You do not need to do this for servlets.)
You want to access only one XA or non-XA resource in a method.
In the component's deployment descriptor, set Local Transactions - Resolution-control to ContainerAtBoundary. In the Container transaction deployment descriptor, set Transaction to Supports.
You want to access several XA resources atomically across one or more bean methods.
In the Container transaction deployment descriptor, set Transaction to Required, Requires new, or Mandatory.
You want to access several non-XA resource in a method without having to worry about managing your own local transactions.
In the component's deployment descriptor, set Local Transactions - Resolution-control to ContainerAtBoundary. In the Container transaction deployment descriptor, set Transaction to Not supported.
You want to access several non-XA resources in a method and want to manage them independently.
In the component's deployment descriptor, set Local Transactions - Resolution-control to Application and set Local Transactions - Unresolved-action to Rollback. In the Container transaction deployment descriptor, set Transaction to Not supported.

Points specific to WebSphere Application Server EnterpriseWBI Server Foundation

You want to access one of more non-XA resources across multiple EJB method calls without having to worry about managing your own local transactions.
In the component's deployment descriptor, set Local Transactions - Resolution-control to ContainerAtBoundary, Local Transactions - Boundary to ActivitySession, and Bean Cache - Activate at to ActivitySession. In the Container transaction deployment descriptor, set Transaction to Not supported and set ActivitySession attribute to Required, Requires new, or Mandatory.
You want to access several non-XA resources across multiple EJB method calls and want to manage them independently.
In the component's deployment descriptor, set Local Transactions - Resolution-control to Application, Local Transactions - Boundary to ActivitySession, and Bean Cache - Activate at to ActivitySession. In the Container Transaction deployment descriptor, set Transaction to Not supported and set ActivitySession attribute to Required, Requires new, or Mandatory.
You want to use a single non-XA resource and one or more XAResources.
Use the Last Participant Support of WebSphere Application Server EnterpriseWBI Server Foundation.

See Also
Local and global transaction considerations
Transaction support in WAS
Configuring transactional deployment attributes using the Assembly Toolkit
Using bean-managed transactions

Develop an enterprise bean or servlet that accesses one or more databases that are independent and require no coordination.	If an enterprise bean does not need to use global transactions, it is often more efficient to deploy the bean with the Container Transaction deployment descriptor Transaction attribute set to Not supported instead of Required. With the extended local transaction support of IBM WAS, applications can perform the same business logic in an unspecific transaction context as they can under a global transaction. An enterprise bean, for example, runs under an unspecified transaction context if it is deployed with a Transaction attribute of Not supported or Never. The extended local transaction support provides a container-managed, implicit local transaction boundary within which application updates can be committed and their connections cleaned up by the container. Applications can then be designed with a greater degree of independence from deployment concerns. This makes using a Transaction attribute of Supports much simpler, for example, when the business logic may be called either with or without a global transaction context. An application can follow a get-use-close pattern of connection usage regardless of whether or not the application runs under a transaction. The application can depend on the close behaving in the same way and not causing a rollback to occur on the connection if there is no global transaction. There are many scenarios where ACID coordination of multiple resource managers is not needed. In such scenarios running business logic under a Transaction policy of Not supported performs better than if it had been run under a Required policy. This benefit is exploited through the Local Transactions - Resolution-control extended deployment setting of ContainerAtBoundary. With this setting, application interactions with resource providers (such as databases) are managed within implicit RMLTs that are both started and ended by the container. The RMLTs are committed by the container at the configured Local Transactions - Boundary; for example at the end of a method. If the application returns control to the container by an exception, the container rolls back any RMLTs that it has started. This usage applies to both servlets and enterprise beans.
Use local transactions in a managed environment that guarantees clean-up.	Applications that want to control RMLTs, by starting and ending them explicitly, can use the default Local Transactions - Resolution-control extended deployment setting of Application. In this case, the container ensures connection cleanup at the boundary of the local transaction context. J2EE specifications that describe application use of local transactions do so in the manner provided by the default setting of Local Transactions - Resolution-control=Application and Local Transactions - Unresolved-action=Rollback. By configuring the Local Transactions - Unresolved-action extended deployment setting to Commit, then any RMLTs started by the application but not completed when the local transaction containment ends (for example, when the method ends) are committed by the container. This usage applies to both servlets and enterprise beans.
Extend the duration of a local transaction beyond the duration of an EJB component method.	The J2EE specifications restrict the use of RMLTs to single EJB methods. This restriction is because the specifications have no scoping device, beyond a container-imposed method boundary, to which an RMLT can be extended. In WBI Server Foundation, you can exploit the Local Transactions - Boundary extended deployment setting to give the following advantages... Significantly extend the use-cases of RMLTs Make conversational interactions with one-phase resource managers possible through ActivitySession support. An ActivitySession is a WBI Server Foundation programming model extension that provides a distributed context with a boundary that is longer than a single method. You can extend the use of RMLTs over the longer ActivitySession boundary, which can be controlled by a client. The ActivitySession boundary reduces the need to use distributed transactions where ACID operations on multiple resources are not needed. This benefit is exploited through the Local Transactions - Boundary extended deployment setting of ActivitySession. Such extended RMLTs can remain under the control of the application or be managed by the container depending on the use of the Local Transactions - Resolution-control deployment descriptor setting.
Coordinate multiple one-phase resource managers.	For resource managers that do not support XA transaction coordination, a client can exploit ActivitySession-bounded local transaction contexts. Such contexts give a client the same ability to control the completion direction of the resource updates by the resource managers as the client has for transactional resource managers. A client can start an ActivitySession and call its entity beans under that context. Those beans can perform their RMLTs within the scope of that ActivitySession and return without completing the RMLTs. The client can later complete the ActivitySession in a commit or rollback direction and cause the container to drive the ActivitySession-bounded RMLTs in that coordinated direction.