Using Connection Pooling
The Microsoft SQL Server JDBC Driver provides support for Java Platform, Enterprise Edition (Java EE) connection pooling. The JDBC driver implements the JDBC 3.0 required interfaces to enable the driver to participate in any connection-pooling implementation that is provided by middleware vendors and is JDBC 3.0-compliant. Middleware such as Java EE application servers frequently provides compliant connection-pooling facilities. The JDBC driver will participate in pooled connections in these environments.
Although the JDBC driver supports Java EE connection pooling, it does not provide its own pooling implementation. The driver relies on third-party Java Application Servers to manage the connections.
The classes for the connection pooling implementation are as follows.
javax.sql.ConnectionPoolDataSource and javax.sql.XADataSource
We recommend that you use the SQLServerXADataSource class for all your Java EE server needs, because it implements all the JDBC 3.0 pooling and XA interfaces.
This class is a connection factory that enables the Java EE application server to populate its connection pool with physical connections. If the configuration of your Java EE vendor requires a class that implements javax.sql.ConnectionPoolDataSource, specify the class name as SQLServerConnectionPoolDataSource. We generally recommend that you use the SQLServerXADataSource class instead, because it implements both pooling and XA interfaces, and has been verified in more Java EE server configurations.
JDBC application code should always close connections explicitly to derive the most benefit from pooling. When the application explicitly closes a connection, the pooling implementation can reuse the connection immediately. If the connection is not closed, other applications cannot reuse it. Applications can use the finally construct to make sure that pooled connections are closed even if an exception occurs.
The JDBC driver does not currently call the sp_reset_connection stored procedure when it returns the connection to the pool. Instead, the driver relies on third-party Java Application Servers to return the connections back to their original states.