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.
With the extended local transaction support of IBM WebSphere Application Server, 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.
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.
You can use an ActivitySession to provide 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.
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.
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.)
In the component's deployment descriptor, set Local Transactions - Resolution-control to ContainerAtBoundary. In the Container transaction deployment descriptor, set Transaction to Supports.
In the Container transaction deployment descriptor, set Transaction to Required, Requires new, or Mandatory .
In the component's deployment descriptor, set Local Transactions - Resolution-control to ContainerAtBoundary. In the Container transaction deployment descriptor, set Transaction to Not supported.
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 .
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.
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.
Use the Last Participant Support .
Related concepts
Local transaction containment (LTC)
Local and global transaction considerations
Transaction support in WebSphere Application Server
Related tasks
Using component-managed transactions
Using one-phase and two-phase commit resources in the same transaction
Using the ActivitySession service
Configuring transactional