JDBC Specification

 JDBC Connection Pool

    * Added by helenlong, last edited by grisdal on Feb 23, 2009  (view change)

Comment:
JDBC Connection Pool

The JDBC Connection Pool page provides information about the connection pool and plots change over time. Connection pool data will only be available if the JDBC resource is deployed and enabled on the server instance or cluster. Because most of the graphs plot change over time, a very lightly loaded system may show little activity. The JDBC connection pool graphs are very similar to the connector connection pool graphs and plot similar data (see Connector Connection Pool).

The following data is displayed.

    * Maximum Pool Size. Maximum number of connections that can be created to satisfy client requests.
    * Leak Reclaim Enabled. If enabled, connection will be reusable (put back into the pool) after connection leak timeout occurs.
    * Datasource Classname. The vendor-specific class name that implements the DataSource and/or XADataSource APIs. This class is in the JDBC driver.

Connection Utilization

    * # of Connections. (Graph) Current status of the connections in this pool.

Data plotted in this graph:

    * Free. Number of connections in the pool available for incoming requests.
    * In Use. Number of connections in the pool currently being used. When the number of in use connections goes up, the number of free connections will drop.
    * In Queue. Number of requests in the queue waiting for available connections.
    * Total Created. Total number of connections ever created for this pool since server startup. For example, if the number in use shows 3, but the total created shows 10, there was a load at some point that spiked to that level.

The Connection Utilization graph works in sync with the Wait Time graph described below. When requests start queueing up and wait times start increasing, that is a sign the pool is under stress. Consider changing the maximum pool size for this connection pool or performing other tuning, keeping in mind that increasing the maximum pool size might decrease the wait time, but it will also increase load on your database.
Wait Time

    * Duration (ms). (Graph) How long users of this pool have been waiting for service in milliseconds. Wait time shows how overloaded the pool might be (if wait time is excessive.)

Data plotted in this graph:

    * Wait Time. How long the last request to the pool waited to get a connection.
    * Average Wait Time. Average wait time for all requests since the server started.
    * Max Wait Time. Longest time a request waited for a connection since the server started. Similar to Total Created above.

Pool Utilization Rate

    * Connections Per Second. (Graph) Plots both the reuse and recycle of connections.

Data plotted in this graph:

    * Reused. Rate at which connections are being acquired (reused) instead of created.
    * Recycled. Rate at which the pool must recycle connections, destroying connections and recreating them.

Pool Life Cycle

    * Connections Per Interval. (Graph) Tracks connection creation and destruction over time for insight into leaks. Pool lifecycle indicates how often connections are being destroyed and recreated. Too often indicates poor pool utilization. If connections are leaking, that may also be revealed in this graph if the create/destroy numbers do not match up over time.

Data plotted in this graph:

    * Created. Number of connections created during this particular interval since the last refresh of the view.
    * Destroyed. Number of connections destroyed during this particular interval since the last refresh of the view.
    * Potential Leaks. Number of connections created but not getting destroyed. Could indicate a leak. This should be zero. If you start seeing a value, further investigation is warranted.

See Also
Monitoring Components and Services
JDBC Resources