Local transaction containment
A local transaction containment (LTC) is used to define the application server behavior in an unspecified transaction context.
Unspecified transaction context is defined in the Enterprise JavaBeans specification, Version 2.0 and later. For example, see the specification for this technology.
An LTC is a bounded unit-of-work scope, within which zero or more resource manager local transactions (RMLT) can be accessed. The LTC defines the boundary at which all RMLTs must be complete; any incomplete RMLTs are resolved, according to policy, by the container. By default, an LTC is local to a bean instance; it is not shared across beans, even if those beans are managed by the same container. LTCs are started by the container before dispatching a method on an enterprise application component, such as an enterprise bean or servlet, whenever the dispatch occurs in the absence of a global transaction context. LTCs are completed by the container depending on the application-configured LTC boundary; for example, at the end of the method dispatch. There is no programmatic interface to the LTC support; LTCs are managed exclusively by the container. The application deployer configures LTCs on individual application components, either web application or EJB, by using transaction attributes in the application deployment descriptor.
A local transaction containment (LTC) might be configured as part of an application component's deployment descriptor to be shareable across multiple application components, including web application components and enterprise beans that use container-managed transactions, so that those components can share connections without using a global transaction. Sharing a single resource manager between application components improves performance, increases scalability, and reduces lock contention for resources.
LTCs can be shared across multiple components, including web application components and enterprise beans that use container-managed transactions. This sharing is useful in situations such as frequent use of web component include() calls, where a thread can have several connections blocked by LTCs in different web modules. In this situation, the application might encounter code deadlocks under load, when threads start to wait for themselves to free connections. To overcome this issue without using a global transaction, specify that application components can share LTCs by setting the Shareable attribute in the deployment descriptor of each component. We must use a deployment descriptor; we cannot specify this attribute if annotation has been used.
When set the Shareable attribute, the extended deployment descriptor XML file includes the following line of code:
- <local-transaction boundary="BEAN_METHOD" resolver="CONTAINER_AT_BOUNDARY" unresolved-action="COMMIT" shareable="true"/>
To obtain the full benefits of a shared LTC, also ensure that the resource reference for each component defaults to shareable connections.
In the following diagram, components 1, 2 and 3 are deployed with the Shareable attribute and component 4 is not. If components 2 and 3 both obtain connections to data source B, and their resource references for data source B default to shareable connections, they share the connection, but component 4 does not.
Applications that use shareable LTCs cannot explicitly commit or roll back resource manager connections used in a shareable LTC. Although, they can use connections that have an autoCommit capability. This ensures correct encapsulation of connection usage by each component and protects one component from having to make any assumptions about the behavior of other components that share the connection.
If an application starts any non-autocommit work in an LTC for which the Resolver attribute is set to Application and the Shareable attribute is set to true, an exception occurs at run time. For example, on a JDBC connection, non-autocommit work is work that the application performs after using the setAutoCommit(false) method to disable the autocommit option on the connection. Enterprise beans that use bean managed transactions (BMT) cannot be assembled with the Shareable attribute set on the LTC configuration.
A local transaction containment cannot exist concurrently with a global transaction. If application component dispatch occurs in the absence of a global transaction, the container always establishes an LTC for enterprise application components at J2EE 1.3 or later. The only exceptions to this are the following items:
- Application component dispatch occurs without container interposition, for example, for a stateless session bean create method or a servlet-initiated thread.
- J2EE 1.2 web components.
- J2EE 1.2 bean-managed transaction (BMT) enterprise beans.
(zos) A local transaction containment cannot exist concurrently with a global transaction. If application component dispatch occurs in the absence of a global transaction, the container always establishes an LTC. The only exception to this behavior is when an application component dispatch occurs without container interposition; for example, for a stateless session bean create method.
A local transaction containment can be scoped to an ActivitySession context that exists longer than the enterprise bean method in which it is started, as described in the topic about ActivitySessions and transaction contexts.
Subtopics
- Local transaction containment
IBM WAS supports local transaction containment (LTC), which we can configure using local transaction extended deployment descriptors. LTC support provides certain advantages to application programmers. Use the scenarios provided, and the list of points to consider, to help decide the best way to configure transaction support for local transactions.
Related concepts
Related tasks