+

Search Tips   |   Advanced Search

 

Local transaction containment considerations

 

IBM WAS supports local transaction containment (LTC), which you can configure using local transaction extended deployment descriptors. This topic describes the advantages that this support provides to application programmers, and the relevant settings to use. It also lists points to consider when deciding the best way to configure transaction support for local transactions.

The following sections describe the advantages that LTC support provides, and how to set the local transaction extended deployment descriptors in each situation.

You can 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 the container commits application updates and cleans up their connections. Applications can be designed with more independence from deployment concerns. This makes using a Transaction attribute of Supports much simpler, for example, when the business logic might 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 the application runs under a transaction. The application can depend on the close behaving in the same way in all situations, that is, it does not cause 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 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 resource manager local transactions (RMLTs) that the container both starts and ends. The container commits RMLTs 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.

You can use local transactions in a managed environment that guarantees cleanup.

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. When the Local Transactions - Unresolved-action extended deployment descriptor is set to Commit, the container commits any RMLTs that the application starts but that do not complete when the local transaction containment ends (for example, when the method ends). This usage applies to both servlets and enterprise beans.

You can 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. 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.

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.

You can 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.

Examples of local transaction support configurations

The following list gives some example scenarios that use local transactions, and some points to consider when deciding the best way to configure the transaction support for an application.

  • You want to start and end global transactions explicitly in the application (bean-managed transaction 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 resources in a method without needing to manage 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.

  • You want to access one or more non-XA resources across multiple EJB method calls without needing to manage 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.



 

Related concepts


Local transaction containment (LTC)
Local and global transaction considerations
Transaction support in WAS

 

Related tasks


Use component-managed transactions
Use one-phase and two-phase commit resources in the same transaction
Use the ActivitySession service
Configure transactional deployment attributes

 

Reference topic