IBM Support

J2CA0086W, LTCs, and Running Out of Shared Connections in WebSphere Application Server

Technical Blog Post


Abstract

J2CA0086W, LTCs, and Running Out of Shared Connections in WebSphere Application Server

Body

A common problem you may have run into is the dreaded running out of connections in your connection pools. This could cause a variety of issues but likely you will see general system slowness, especially for applications directly using the database.

A very good webcast replay from our popular WebSphere Support Technical Exchange covering the various reasons for full connection pools is located here: Understanding and Resolving ConnectionWaitTimeout Exceptions in WebSphere Application Server

This blog post will cover a bit more about Shareable Connections running in a Local Transaction Containment.

Shareable Connections are set to default in WebSphere Application Server. Shareable connections are actually only fully utilized if you carefully plan for them. Shareable connections are only truly reused when all of the following are true: Both connections are in the same JVM, use the same transaction manager, have identical properties, marked as shareable, and are both used within a container managed or bean managed transaction scope.

Even when all of those conditions are met, you may still not see any benefits of shared connections over unshared connection on systems that constantly keep connections open by using them. When using unshared connections that are available in the free pool they remain open to the database and new requests don't pay the penalty of opening a new physical connection.

There are several possible pitfalls to consider when using Shareable Connections:

  • Transactional behavior
    • WebSphere Application Server has a transactional concept called Local Transaction Containment (LTC). This is our answer to the unspecified transaction condition in the EJB specification when a transaction is not a Global Transaction. When you are using a shareable connection in a LTC and don't close it, you will see the following warning in your logs:

J2CA0086W: Shareable connection {0} from resource {1} was used within a local transaction containment boundary.

This warning is issued because even if you use the connection as shared connection and not close the connection before get connection again from same pool, if you don't use it as  get -> use -> close pattern for your connections, when get connection again in same LTC, a new connection from free pool will be allocated to the LTC. This can lead to multiple connections being in use in same LTC for a long period of time as shared connections. If you have several LTCs using multiple shareable connections in single LTC, it can be enough to keep all connections in the pool in use resulting in J2CA0045E.

  • Servlets
    • Servlets use LTCs in WebSphere Application Server by default. If the servlet uses data source connections, those connections will remain in use and unusable by other applications until the doService() method ends.

To resolve J2CA0086W warnings, please always close connection immediately after finish use the connection even if it is a shared connection and close connection in finally of try/catch/finally.

If it runs out of connections and the connections are used as shared connections, but in same LTC, the connections are not reused repeatedly in same LTC or between the time to reuse the connection, there are many business codes to run, then you can change to use connections as unshared connections to improve performance.

  1. In most cases Using unshareable connections will not result in a performance hit. We do encourage performance testing if there is doubt that unshareable is not performing as well as shareable in your environment, please always use connection with get/use/close mode and close connection in finally of try/catch/finally no matter if you use it as shared or unshared connection to avoid connection leak issue and improve performance. There are two ways to change to unshareable connections in WebSphere Application Server:
    1. Modify data source setting defaultConnectionTypeOverride as described in the product documentation: Tuning connection pools
    2. or Modify the resource reference of your application so that the Sharing Scope is Unshareable per this topic in the product documentation: Creating or changing a resource reference
  2. Enclose the connection portion into a UserTransaction which is part of the Java™ Transaction API. The transaction will begin as a LTC, but be suspended when the connection starts the Global Transaction. The connection will be released to the free pool when the Global Connection ends and the LTC continues. Please note that, for the connections open in LTC scope before global transaction begin, shared connection will be closed automatically before begin global transaction, but unshared connection open in LTC before global transaction begin will be closed when LTC end. This method is generally not recommended over the use of unshareable connections as creating the UserTransaction can have a performance impact. We would generally only recommend trying this if the use of unshareable connections also effects performance.

Again, please always close connection immediately after finish use the connection no matter it is a shared or unshared connection and close connection in finally of try/catch/finally.

title image (modified) credit: (cc) Some rights reserved by Nemo

[{"Type":"MASTER","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":"a8m50000000CdYAAA0","label":"WebSphere Application Server traditional-All Platforms-\u003EJ2C-ConnectionPooling-JDBCDrivers-\u003EConnection Pooling-J2C-DB Connections-\u003EConnection Pooling"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

UID

ibm11080447