thank you steve,
The broken Connection will have been "excluded". When you call close() it will be silently destroyed by the pool rather than retained for future use.
On Jul 2, 2012, at 5:18 PM, sakin cali wrote:
> Hi Steve,
> c3p0 automatically tests Connections following Exceptions, and if it deems them broken, the Connections are not placed back in the pool.
> You mean, when I call con.close() connection is not placed back to pool?
> If this is the case, when will the substitute connection is created?
The Connection will be replaced as necessary in the course of c3p0's ordinary Connection acquistion in response to client demand, as controlled by maxPoolSize, acquireIncrement, etc.
When you call con.close(), c3p0 quietly "checks in" the underlying resource to its internal pool. If you set c3p0.testConnectionOnCheckin to true, then after con.close() is called but before the recycled Connection is made available to other clients, the Connection will be tested (and destroyed if it seems broken).
> it is possible that a Connection could break or time out between the client's last use and its check-in to the pool. you can prevent this bu setting c3p0.testConnectionOnCheckin to true. (Setting this parameter to true as well as an idleConnectionTestPeriod is one of the best Connection testing strategies to use, see http://www.mchange.com/projects/c3p0/#configuring_connection_testing
> Steve, what does "check-in" exactly mean? Placing connection back to the pool with con.close()?
An advantage of this technique, unlike c3p0.testConnectionOnCheckout, is that check-in tests are asynchronous from clients' perspective. No client has to wait for the test to complete; it is performed by c3p0's helper threads in the course of pool maintenance.