IBM Support

Default behavior of managed connections in WebSphere Application Server

White Papers


Abstract

Local transaction containment (LTC) is a default transaction context that acts as a safety net to prevent leaking of JCA managed connections in IBM WebSphere Application Server. This default behavior is beneficial to many applications, but can have unintended consequences for others. This article describes some scenarios where changes to the application design or this default configuration would be beneficial.

Content

Introduction
Whether discussing automobiles, the company medical plan, or a personal computer, most of us could agree on one point: the default configuration -- while useful in many cases -- may not necessarily be right for everyone. So it is with managed connections in IBM WebSphere Application Server. We will look at various aspects of the default behavior of managed connections in WebSphere Application Server and identify some situations where you might want to consider changing the configuration to better suit your application requirements.

Transaction basics

A transaction can be described as a unit of work in which multiple updates to resources are made atomically; meaning that either ALL the resource updates will be made permanent if the transaction is committed, or NONE of the resource updates will occur if the transaction is rolled back. Transactions can be broadly categorized as either global or local:
  • Global transaction context - A global transaction is also referred to as a distributed transaction, an XA transaction, a 2PC (2-phase commit) transaction, or just a transaction. This type of transaction is global, or distributed, in the sense that multiple resource managers may be accessed within the transaction and the transaction manager has the ability to coordinate among all the resource managers to ensure the atomicity of updates. Conversely, a local transaction involves only a single resource manager.
    A global transaction context may be created automatically for Enterprise Java™ Bean (EJB) methods by using container managed transaction support and specifying an appropriate transaction attribute for the method. The Java Transaction API (JTA) UserTransaction interface may also be used to create a global transaction context from within a servlet, a message driven bean, or an EJB component that specifies the use of bean managed transactions. Use of the UserTransaction interface is optional, however, so in its absence WebSphere Application Server provides an alternate transaction context.
  • Local transaction containment - The EJB 2.0 specification states that an application which operates outside of a global transaction executes instead under an "unspecified" transaction context. Naturally, an implementation of a Java Platform, Enterprise Edition (JEE) application server cannot behave randomly, and so the application server must specify its implementation of the unspecified context. In the case of WebSphere Application Server, this context is defined as a local transaction containment (LTC). The LTC functions as an implicit, containing scope for any local transactions that occur within the LTC boundaries. The initiator of a local transaction is expected to complete each local transaction within the LTC boundary. Typically, this is accomplished by having the connection's auto-commit mode set to true or, if auto-commit is set to false, the application would explicitly call Connection.commit() or Connection.rollback(). However, the (web or EJB) container is charged with completing any outstanding local transactions at the end of the LTC boundary. This serves as a safety net for defective applications, which fail to complete their own transactions. The container will also release to the free connection pool any outstanding connections associated with the LTC.
    The 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. More information can be found in Configuring transactional deployment attributes page.
Connection pooling and shareable connections

Connection pooling in WebSphere Application Server is managed according to the Java Connector Architecture (JCA) and enables the use of shareable or unshareable connections. In WebSphere Application Server, connections are shareable by default. The use of shareable connections means that, if conditions allow it, different getConnection requests by the application will actually receive a handle (indirectly) for the same physical connection to the resource. The benefits of this are improved performance and a reduction in the number of physical connections that need to be managed.

The JCA 1.0 specification has the following to say about shareable connections:

When multiple shareable connections x and y acquired by an application are used within a global transaction scope (for instance, container-managed or bean-managed), the application server must provide a single shared connection behavior under the following conditions:
  • X and Y are collocated in a single Java virtual machine process address space.
  • X and Y are using a single transactional resource manager.
  • X and Y have identical properties.
  • X and Y are marked as shareable.
  • X and Y are used within a container-managed or bean-managed transaction scope. The ability to share is unspecified for connections marked shareable that are used outside a global transaction scope. Sharing is not supported for connections obtained from a non-transactional resource adapter, that is, transaction support level is NoTransaction.
Once again, we have an "unspecified" case about connection sharing in the absence of a global transaction scope; that is, within an LTC scope. WebSphere Application Server has defined its behavior in this case with the assumption of serial reuse for shareable connection requests. Serial reuse is also referred to as get/use/close, get/use/close, where the expectation is that the application gets a connection, use it, and then close it while doing other processing before(possibly) getting another connection to the same resource. One key point regarding this behavior is that when the application closes a shareable connection, the connection is not truly closed, nor is it returned to the Free pool. Rather, it remains in the Shared connection pool, ready for another request within the same LTC for a connection to the same resource.
The use of shareable connections can provide performance benefits in many situations, but you need to be aware of this default behavior and take it into account when developing applications. Otherwise, the application could experience problems under heavy workload.

LTC-related behaviors

Servlets

When a servlet is invoked, the web container in WebSphere Application Server automatically creates an LTC context. If a shareable Java Database Connectivity (JDBC) connection is obtained within that LTC, the connection pooling code allocates the managed connection in the shared pool, where it is marked as having an affinity to the current LTC. As stated earlier, when the application closes the connection, it is not returned to the free pool, but is kept reserved for possible further use in that LTC. The connection is not returned to the free pool until the LTC ends. The LTC does not end until the servlet doService() method ends.
If a servlet gets a connection, uses it, and closes it, but then remains in the servlet for a relatively long time, that connection remains unavailable for use by other threads. In times of heavy workload, such a situation can lead to a shortage of available connections.
Likewise, if the servlet obtains a connection and then passes control to another servlet (via forward or include), or to an EJB, then the connection remains unavailable for use until control returns to the first servlet and the first servlet ends. Furthermore, when control is passed out of the first servlet, a new transaction context is created. Thus if another connection to the same resource is requested within the new transaction context, the connection held by the first servlet cannot be shared. A new connection must be allocated with affinity to the new transaction context. The thread in this case is now holding two connections from the same pool. The outline below shows how this scenario might look, creating the danger of a deadlock on the connection pool if too many threads do this concurrently. A situation could develop where all the connections available in the pool are held by different threads, and each thread that is holding a connection is trying to get another connection when none are available. This deadlock persists until ConnectionWaitTimeouts cause threads to return a failure response and release their connections.
  • LTC A begins
  • Servlet A begins
    • Get Connection A //shareable
    • Use Connection A
    • Close Connection A
    • // Connection A remains in shared pool, associated with LTC A
    • Include or forward servlet B
    • LTC A suspends
    • LTC B begins
      • Servlet B begins
        • Get Connection B //shareable
        • Use Connection B
        • Close Connection B
        • // Connection B remains in shared pool, associated with LTC B
      • Servlet B ends
    • LTC B ends //Connection B released to free pool
    • LTC A resumes
    • // possible Connection A reuse (get/use/close)
  • Servlet A ends
  • LTC A ends //Connection A released to free pool
Filters
Filters are related to servlets and are inserted in the HTTP request/response flow by the web container, such that the filter may access the request/response data before the servlet starts, and again after the servlet ends. Each filter shares LTC context with the associated servlet.
Solutions and caveats
If an application is structured, as in the above scenarios, and is using multiple connections per thread, then take measures to minimize the number of connections needed and protect against the deadlock scenario. Some suggestions follow on how to do that.
Unshareable connections
The behaviors described above were all predicated on the use of shareable connections. When Connection.close() is called on the shareable connection obtained in an LTC, the connection remains in the shared pool. In this way, the application behavior of serial reuse is accommodated with minimum latency. Conversely, if an unshareable connection is used, there is no assumption that the connection may be reused within the LTC. Indeed, the unshareable connection has no LTC affinity. A more conventional behavior occurs such that, when the application executing in an LTC closes the connection, the connection is immediately returned to the free pool, even though the current LTC has not ended. If control then passes to another servlet, for example, and a new LTC context is created, a connection obtained in the new context will be the only connection held by that thread.
If the application is correctly using resource references, then this solution is quite attractive, since the change from shareable to unshareable connections is as easy as modifying the appropriate resource references in the deployed application and then reinstalling the application. A possible downside to this approach is that, since the unshareable connection has no affinity to the LTC, the LTC is unable to provide the previously mentioned "safety net" to prevent a leaked connection. However, this is much preferred over the potential for deadlock if the application would otherwise be using multiple connections per thread.
UserTransactions
A way to make a shareable connection get released to the free pool before the LTC ends is to keep it from being associated with the LTC. This can be done by enclosing the use of the connection in a global transaction via the UserTransaction interface of the Java Transaction API. As before, the LTC is active initially, but when the global transaction is started, the LTC is suspended. A shareable connection obtained within the global transaction is released to the free pool when the transaction is ended. The point where that occurs is now under the control of the application.
The use of global transactions within the LTC incur more overhead in terms of application complexity and also in terms of performance. Additionally, the use of the UserTransaction interface from within a servlet filter is prohibited by the JEE specification.
Application structure
Another solution may be to restructure the application to isolate the use of shareable connections so that they become naturally associated with separate transaction contexts rather than the main path LTCs. As an example, a main path servlet could include a separate servlet or call an EJB to access a resource. When control returns to the main servlet, any connections used will have been released. In this way, the application can make the default behaviors work in its favor. Such structure is also good for modularity of the application and may enhance reuse and application longevity.
The disadvantage to restructuring the application is, well, the application needs to be restructured.
Conclusion
WebSphere Application Server provides local transaction containment as a default transaction context in the absence of a global transaction context. Shareable connections obtained by an application within an LTC are kept reserved in the shared pool for use within that LTC until the LTC ends, even if the application closes the connection. This behavior is beneficial to many applications, but can have unintended consequences for others. Depending on the application design, some modifications to the application or the configuration may be desirable to ensure the application's reliability in times of heavy workload.
Related topic

[{"Type":"SW","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"ARM Category":[{"code":"a8m50000000CdUNAA0","label":"J2C-ConnectionPooling-JDBCDrivers-\u003EConnection Pooling-J2C-DB Connections-\u003EShareable vs. Unshareable"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]

Document Information

Modified date:
23 August 2023

UID

ibm16447015

Page Feedback