Chapter 11. Jdbc And Sqlj Connection Pooling Support - IBM DB2 Manual

Chapter 11. JDBC and SQLJ connection pooling support

Connection pooling is part of JDBC DataSource support, and is supported by the
IBM Data Server Driver for JDBC and SQLJ.
The IBM Data Server Driver for JDBC and SQLJ provides a factory of pooled
connections that are used by WebSphere Application Server or other application
servers. The application server actually does the pooling. Connection pooling is
completely transparent to a JDBC or SQLJ application.
Connection pooling is a framework for caching physical data source connections,
which are equivalent to DB2 threads. When JDBC reuses physical data source
connections, the expensive operations that are required for the creation and
subsequent closing of java.sql.Connection objects are minimized.
Without connection pooling, each java.sql.Connection object represents a physical
connection to the data source. When the application establishes a connection to a
data source, DB2 creates a new physical connection to the data source. When the
application calls the java.sql.Connection.close method, DB2 terminates the
physical connection to the data source.
In contrast, with connection pooling, a java.sql.Connection object is a temporary,
logical representation of a physical data source connection. The physical data
source connection can be serially reused by logical java.sql.Connection instances.
The application can use the logical java.sql.Connection object in exactly the same
manner as it uses a java.sql.Connection object when there is no connection
pooling support.
With connection pooling, when a JDBC application invokes the
DataSource.getConnection method, the data source determines whether an
appropriate physical connection exists. If an appropriate physical connection exists,
the data source returns a java.sql.Connection instance to the application. When
the JDBC application invokes the java.sql.Connection.close method, JDBC does
not close the physical data source connection. Instead, JDBC closes only JDBC
resources, such as Statement or ResultSet objects. The data source returns the
physical connection to the connection pool for reuse.
Connection pooling can be homogeneous or heterogeneous.
With homogeneous pooling, all Connection objects that come from a connection
pool should have the same properties. The first logical Connection that is created
with the DataSource has the properties that were defined for the DataSource.
However, an application can change those properties. When a Connection is
returned to the connection pool, an application server or a pooling module should
reset the properties to their original values. However, an application server or
pooling module might not reset the changed properties. The JDBC driver does not
modify the properties. Therefore, depending on the application server or pool
module design, a reused logical Connection might have the same properties as
those that are defined for the DataSource or different properties.
With heterogeneous pooling, Connection objects with different properties can share
the same connection pool.
© Copyright IBM Corp. 1998, 2008
Related reference
465