Most clients need never use or know about this interface -- c3p0 pooled DataSources can be treated like any other DataSource.
The functionality in this interface will be only be of interest if 1) for administrative reasons you like to keep close track of the number and status of all Connections your application is using; 2) to work around problems encountered while managing a DataSource whose clients are poorly coded applications that leak Connections, but which you are not permitted to fix; or 3) to work around problems that may occur if an underlying jdbc driver / DBMS system is unreliable. In the third case, most users will be better off not using the present interface at all, and using the DataSources' maxIdleTime, idleConnectionTestPeriod, or testConnectionOnCheckout parameters to help your DataSources "automatically" heal. But for those who prefer a more direct, manual approach, this interface is for you. It is anticipated that the methods of this interface will primarily be of use to administrators managing c3p0 PooledDataSources via JMX MBeans.
To understand this interface, you need to realize that a c3p0 PooledDataSource may represent not just one pool of Connections, but many, if users call the method Connection getConnection(String username, String password) rather than the no-argument getConnection() method. If users make use of non-default username, password combinations, there will be a separate pool for each set of authentification criteria supplied.
Many methods in this interface have three variants:
The first variant makes use of the pool maintained for the default user -- Connections created by calls to the no argument getConnection(), the second variant lets you keeps track of pools created by calling getConnection( username, password ), and the third variant provides aggregate information or performs operation on all pools.
Under most circumstances, non-default authentication credentials will not be used, and methods of the first variant are sufficient to manage the DataSource.
A properly configured PooledDataSource whose applications are careful to close all checked-out Connections would never need to use these methods. But, sometimes applications are untrustworthy and leak Connections, or database administrators suspect that Connections may be corrupt or invalid, and would like to force a pool to flush and acquire fresh Connections. This interface provides two ways to do so.
For each per-user pool, four different statistics are available:
|
|