Use local transactions

WAS uses local transaction containment (LTC) support, which is configured through local transaction extended deployment descriptors. Consider the following 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 WAS, applications can perform the same business logic in an unspecific transaction context as they can under a global transaction. For example, an enterprise bean 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 where 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. For example, using a Transaction attribute of Supports is much simpler when the business logic may be called 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 resource manager local transactions (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, they are committed 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 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 are provided by the default setting of Local Transactions -Resolution-control equal to Application and Local Transactions - Unresolved-action equal to Rollback. By configuring the Local Transactions - Unresolved-action extended deployment setting to Commit, 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.

• 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 to best configure the transaction support for an application, depending on what you want to do with transactions, consider the following 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.