Learning more about Connection Pooling (J2C)
 Technote (troubleshooting)
 
Problem(Abstract)
Learning more about connection pooling (J2C) is the first step in the troubleshooting process. This document provides you with educational information that can help you learn more about this topic.
 
Resolving the problem

1. Learning more 2. Troubleshooting 3. Collecting data

Getting background information on Connection Pooling and J2C
  • What is connection pooling?
    IBM® WebSphere® Application Server provides connection pooling for Java™ Database Connectivity (JDBC), Java Message Service (JMS), and Enterprise Information System (EIS) connections. The purpose of pooling connections is to improve performance by reducing the overhead involved in creating a new connection every time the application requests one. Connection pooling allows J2EE applications to reuse connections to databases and other backend systems for multiple requests. For further information on connection pooling refer to Connection pooling in the WebSphere Application Server Information Center.

    WebSphere Application Server V5.0 and V5.1 support the Java Connector Architecture (JCA) 1.0 specification. WebSphere Application Server V6.0 supports the JCA 1.5 specification.

    For JDBC connections, there is one connection pool for each data source that is created in WebSphere Application Server. There are two types of data sources that can be created. These are standard data sources (sometimes referred to as V5 or V6 data sources) and Version 4 data sources. Version 4 data sources are only used with J2EE 1.2 applications that have been migrated from WebSphere Application Server V4 to V5 or V6. For information on Version 4 data source connection pool configuration, see Connection Pool (Version 4) settings. Standard data sources can be used by J2EE 1.3 or J2EE 1.4 applications.

    Connection pools are configured in the WebSphere Application Server Administrative Console under Resources. For information on configuring JDBC connection pools, see Connection pool settings. For information on configuring Version 4 data source connection pools, see Connection pool (Version 4) settings.

  • JMS Connection Pools
    WebSphere Application Server pools both JMS connections and JMS sessions. This is different from JDBC connection pooling in that there are two levels of pooling. A JMS application will call createQueueConnection() on a connection factory to get a JMS connection object from the connection pool and then call createQueueSession() on the connection to get a JMS session object from the session pool. Each connection has its own session pool. More details about how JMS connection pooling works can be found in this technote. For more information on configuring JMS connection pools, see Connection pool settings and Session pool settings.

  • What are the best programming practices when using a connection pool?
    When using a connection pool, it is important to follow specific programming practices to make connection pooling work most efficiently and to prevent problems. One of the most important practices is to always call close() on a connection object as soon as the application finishes using it. This is necessary so that the connection can return to the free connection pool. Care should be taken to make sure connections are closed even in exception condition. Failing to close connections means that connections are leaked, reducing the number of connections available in the connection pool, and leading to ConnectionWaitTimeoutExceptions. For more information on this, you can become familiar with the connection life cycle.

    If a JDBC or JMS connection becomes invalid while it is in a connection pool, then a StaleConnectionException will occur when an application tries to use the connection. WebSphere Application Server will then discard its reference to the connection and purge the connection pool based on the Purge Policy setting. The best practice for dealing with stale connections is to handle them in the application by catching the StaleConnectionException and then retrying the connection (after the pool is purged). For more information about this, see this technote, this Information Center reference on stale connections, and this Information Center reference on how to handle the StaleConnectionException. Another option is to pretest each connection to check for invalid connections, but this does add the overhead of running a test query on every connection allocation. Here is more information on pretesting connections.

    For more information on best programming practices for connection pools, see this article.

  • Shareable vs. Unshareable Connections
    The JCA specification defines two different types of connections, shareable and unshareable. Shareable connections can be shared within a transaction if the connection properties are the same. When shareable connections are used, each time a connection to the same resource is allocated, a connection handle to the same physical connection is returned to the application. With unshareable connections, there is only one handle per physical connection. The default connection type is shareable for JDBC connections and unshareable for JMS connections. The default can be changed in the resource reference that is used to access the resource. A key point is that shareable connections are shared within the scope of a single transaction. Also, shareable connections are not returned to the free connection pool, even after the application calls close() on the connection, until the transaction is committed. This could cause unexpected consequences, which are documented here. More information about shareable and unshareable connections can be found here.

  • J2C Authentication
    In WebSphere Application Server, J2C authentication aliases can be configured to hold the user ID and password that are used to connect to a backend resource. The authentication alias is then specified on the data source or connection factory in order to authenticate the user when establishing a connection. Most databases, messaging systems, and enterprise information systems require a user ID and password. A common cause of a connection problems is a problem with authentication. For more information on J2C authentication, see this technote.
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > DB Connections/Connection Pooling
Operating system(s): Windows
Software version: 6.0
Software edition:
Reference #: 1247167
IBM Group: Software Group
Modified date: Dec 3, 2007