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.
|