IBM Support

Connection leak or ConnectionWaitTimeoutException when using asynchronous beans in WebSphere Application Server

Troubleshooting


Problem

When running an asynchronous bean application in WebSphere® Application Server, ConnectionWaitTimeoutExceptions or connection leaks may occur even if the maximum connection pool size is set high enough and the application is closing connections as soon as it finishes using them.

Cause

In WebSphere Application Server, a ConnectionWaitTimeoutException is thrown when the connection pool is at its maximum size, all of the connections are in use by the application, and the application requests more connections.

If the problem only happens under heavy load, it is likely that the maximum connection pool size needs to be increased to handle the increased load.

In other cases, the pool is at its maximum size because connections have not been explicitly closed by the application to return them to the free pool; in other words, connections have been leaked.

Connection leaks may be detected by analyzing the connection pool usage with the Tivoli Performance Viewer.

You may notice a connection leak in an asynchronous bean application even if the application is closing all of the connections that it obtains immediately after it finishes using them.

This occurs because a local transaction containment (LTC) is started when an asynchronous bean is called.

When a connection is obtained in an LTC, the default behavior is that the connection does not return to the free pool until the LTC ends. The LTC does not end until the asynchronous bean method completes.

If the asynchronous bean performs a long-running task, the connection may remain allocated to the application for a long period of time. The effect of this is that the connection is leaked. When many connections are leaked, ConnectionWaitTimeoutExceptions may occur.

Resolving The Problem

To resolve the problem, connections must return to the free pool immediately after the application closes them. This can be accomplished in two ways:

  • Use unshareable connections instead of shareable connections. Shareable connections are the default. The differences between shareable and unshareable connections are described here.
  • When unshareable connections are used, the connection behavior in an LTC changes. The connections are returned to free pool immediately when they are closed by the application.

    You can select whether to use shareable or unshareable connections in the resource reference. The application must do an indirect JNDI lookup (using the java:comp/env context) of the data source or connection factory so that the resource reference settings are used.

  • Modify the application so that the connection usage is encapsulated within a global transaction. This can be done by creating a UserTransaction within the asynchronous bean and obtaining, using, and closing the connection within the UserTransaction. When the global transaction ends, the connection will return to the free pool.

[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Programming Model Extensions (PME)","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.0;8.5.5;8.0;7.0","Edition":"Base;Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSNVBF","label":"Runtimes for Java Technology"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Java SDK","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
15 June 2018

UID

swg21225611