Comment lines: Using JCA connections in applications for scalability

IBM® WebSphere® Application Server JCA connection manager provides connection pooling. It enables administrators to establish a pool of connections that can be used by applications running on an application server. If not used appropriately, these connections will exhaust the connection pool and limit scalability. This article provides insights into application usage scenarios that could limit efficient utilization of JCA connections. This content is part of the IBM WebSphere Developer Technical Journal.


Anoop Ramachandra (, Senior Staff Software Engineer , IBM

Author photoAnoop Ramachandra is a Senior Staff Software Engineer in IBM India Software Labs. He has over eight years of experience on WebSphere Application Server product as a Technical Lead, developer and Level 3 support engineer. His major areas of expertise in WebSphere Application Server include System Management, Java EE Connector Architecture, Virtual Member Manager, Scheduler and Asynchronous beans. He is an IBM Certified System Administrator for WebSphere Application Server.

20 March 2013

Also available in Chinese


The connection management architecture for both relational and procedural access to enterprise information systems (EIS) is based on the Java™ EE Connector Architecture (JCA) specification. The Connection Manager (CM), which pools and manages connections within an application server, is capable of managing connections obtained through both resource adapters (RAs) defined by the JCA specification, and data sources defined by the Java Database Connectivity (JDBC) specification. IBM WebSphere Application Server enables administrators to establish a pool of back end connections that applications can share on an application server. Connection pooling can improve the response time for applications because the overhead of creating a new connection is avoided for every new request to access the backend resource.

Optimal connection usage

Typically, the application component does a lookup of a connection factory in the Java Naming and Directory Interface (JNDI) name space and then uses the connection factory to get a connection to the underlying EIS. Careful usage of these connections can avoid connections becoming exhausted, and can also help applications scale.

Here are the precautions you must take in order to achieve optimal connection usage:

  • Explicit and immediate connection close

    The application component invokes the getConnection method on the connection factory to get an EIS connection. The returned connection instance represents an application-level handle to an underlying physical connection. After the application component finishes with the connection, it should close the connection using the close method on the Connection interface. If an application component fails to close an allocated connection after its use, that connection is closed by the application server only as part of cleanup of the transaction later. This would deny other requests to use that connection and limit scalability.

    The application component is recommended to explicitly close the connection handle as soon as the handle has been used and is not required later. This reduces the possibility of connection leaks and enhances the application server’s ability to pool physical connections to the EIS.

  • Shared connections and LocalTransactionContainment

    Connections in WebSphere Application Server are shared by default. The use of a shareable connection means that, if conditions allow it, different getConnection() requests by an application will actually receive a handle for the same physical connection to the resource. For shared connections, the sharing scope is transaction. An application which operates outside of a global transaction acquires a default context in WebSphere Application Server called LocalTransactionContainment(LTC).

    The shared connections will not be available for requests from other transactions until the LocalTransactionContainment ends. So it is always prudent to not have long running and nested LocalTranactionContainment that holds on to shared connections for long periods of time and leads to connection pool exhaustion.

    An application component can use the JTA UserTransaction interface or a transaction demarcation API specific to an EIS to control the transaction boundaries and avoid long running LTC.

  • Long running queries

    A slow running query will hold the connection to a database and that connection will not be available to be used by any new requests trying to access the same resource. A connection can process only one operation at any point in time; for example, if a query takes 10 seconds, then another request to the same resource would be blocked to utilize that connection. Further, slow running queries combined with higher load would eventually lead to the connection pool getting exhausted. It would be helpful to constantly monitor UseTime and other statistics by enabling connection pool statistics as part of your Performance Monitoring Infrastructure.

  • Unshared connections

    Access to a resource marked as unshareable means that there is a one-to-one relationship between the connection handle a component is using and the physical connection with which the handle is associated. This access implies that every call to the getConnection method returns a connection handle solely for the requesting user. Typically, you must choose unshareable if you might do things to the connection that could result in unexpected behavior occurring in another application that is sharing the connection.

    Choosing unshared connections might increase the number of connections being used and lead to connection pool exhaustion at higher load as a new connection will be used for every request.

  • AutoCommit and LocalTransactionContainment

    When a connection is in an auto-commit mode, an operation on the connection automatically commits after it has been executed. The auto-commit mode will be off if multiple interactions have to be grouped in a single transaction, either local or XA, and committed or rolled back as a unit.

    For connections that are used outside a transaction, the auto-commit mode is set to true and LocalTransactionContainment will be active. When using Unshared connections, if Autocommit is set to false by the application, then the connection will not be available for other requests even with applications closing the connection. An application has to invoke commit on a connection object explicitly prior to closing the connection.

  • Transaction Isolation and Read Only properties

    An application that changes the transaction isolation level or read only properties would be provided with a new connection rather than providing the same shared connection, even in the same transaction. Frequent changes to the transaction isolation level from the application will render different connections and increase the number of connections needed, ultimately leading to exhausting the connection pool.

  • Principal

    The same principal means the same user and password are required for relational databases. If applications use a different user ID and password to acquire the connection, the physical connections returned from the getConnection calls will be different. When an application's resource authentication setting is set to Application, you can acquire the connections with either getConnection() or getConnection(String userid, String password). The connections acquired from these two calls are not shared, even if the component-managed authentication alias associated with the datasource has the same user ID and password used in getConnection(String userid, String password).

  • Unshareable JMS sessions

    JMS connections for the JMS provider will not be shareable because they are non-transactional, and the Java EE Connector Architecture (JCA) specification only permits transactional resources to be shareable. If the res-sharing-scope is set to shareable in a JMS resource reference, the setting will be ignored and unshareable connections will be used. However, JMS sessions are transactional, and can be shareable. JMS sessions are shareable by default.

    When a shareable JMS session gets enlisted in the Transaction, closing the session will not release it to the pool. However, closing the connection makes the connection available to other applications. Next, when the same application asks for a connection, in some instances it might probably get a new connection and in such scenarios a new session will be created when the application creates a session.

    In such scenarios, to release the session to the pool as soon as it is closed, sessions can be made unshareable as well. This means that whenever an application calls Session.close(), the JMS session is automatically released from any transaction that it is associated with and returned to the session pool. It would be appropriate to confirm the above scenario and understand other implications before making sessions unshareable.


Application usage of JCA connections plays an important role in optimal usage of pooled connections. Following some usage patterns and having knowledge of connection behavior can help avoid exhausting the connection pool and help supplement scalability.


The author thanks Murali K Surampalli and Rispna Jain for their valuable suggestions and feedback.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Comment lines: Using JCA connections in applications for scalability