thank you steve,

great explanation,

On 2 July 2012 18:02, Steve Waldman <swaldman@mchange.com> wrote:

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 broken Connection will have been "excluded". When you call close() it will be silently destroyed by the pool rather than retained for future use.

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.

>
>
> 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()?

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).

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.

   smiles,
      Steve