Thread: [c3p0-users] LifeCycle of a connection in c3p0
Status: Beta
Brought to you by:
swaldman
From: sakin c. <sak...@gm...> - 2012-07-02 13:21:31
|
Hi, When do problematic connections in a pool refreshed? For example, given the steps below, when does the connection is refreshed? 1. Create pool: cpds.setAcquireRetryAttempts(5); cpds.setAcquireRetryDelay(200); cpds.setPreferredTestQuery(SQLContainer.CONNECTION_TEST_SQL); cpds.setForceIgnoreUnresolvedTransactions(true); cpds.setConnectionCustomizerClassName("com.intellica.evam.engine.db.EvamConnectionCustomizer"); 2. Get connection conn = cpds.getConnection() 3. Use connection .. .. .. .. exception : db connection is closed (somehow) .. 4. Put connection back to pool conn.close 5. Get connection conn = cpds.getConnection() |
From: Steve W. <swa...@mc...> - 2012-07-02 13:34:09
|
hi, c3p0 automatically tests Connections following Exceptions, and if it deems them broken, the Connections are not placed back in the pool. 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 smiles, steve if you are concerned that On Jul 2, 2012, at 4:21 PM, sakin cali wrote: > Hi, > > When do problematic connections in a pool refreshed? > For example, given the steps below, when does the connection is refreshed? > > 1. Create pool: > > cpds.setAcquireRetryAttempts(5); > cpds.setAcquireRetryDelay(200); > cpds.setPreferredTestQuery(SQLContainer.CONNECTION_TEST_SQL); > cpds.setForceIgnoreUnresolvedTransactions(true); > cpds.setConnectionCustomizerClassName("com.intellica.evam.engine.db.EvamConnectionCustomizer"); > > 2. Get connection > > conn = cpds.getConnection() > > 3. Use connection > .. > .. > .. > .. > exception : db connection is closed (somehow) > .. > > 4. Put connection back to pool > conn.close > > 5. Get connection > > conn = cpds.getConnection() > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users |
From: sakin c. <sak...@gm...> - 2012-07-02 14:19:01
|
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? > > 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()? > smiles, > steve > > > if you are concerned that > On Jul 2, 2012, at 4:21 PM, sakin cali wrote: > > > Hi, > > > > When do problematic connections in a pool refreshed? > > For example, given the steps below, when does the connection is > refreshed? > > > > 1. Create pool: > > > > cpds.setAcquireRetryAttempts(5); > > cpds.setAcquireRetryDelay(200); > > cpds.setPreferredTestQuery(SQLContainer.CONNECTION_TEST_SQL); > > cpds.setForceIgnoreUnresolvedTransactions(true); > > > cpds.setConnectionCustomizerClassName("com.intellica.evam.engine.db.EvamConnectionCustomizer"); > > > > 2. Get connection > > > > conn = cpds.getConnection() > > > > 3. Use connection > > .. > > .. > > .. > > .. > > exception : db connection is closed (somehow) > > .. > > > > 4. Put connection back to pool > > conn.close > > > > 5. Get connection > > > > conn = cpds.getConnection() > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > > c3p0-users mailing list > > c3p...@li... > > https://lists.sourceforge.net/lists/listinfo/c3p0-users > > |
From: Steve W. <swa...@mc...> - 2012-07-02 15:02:30
|
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 |
From: sakin c. <sak...@gm...> - 2012-07-07 10:33:59
|
thank you steve, great explanation, On 2 July 2012 18:02, Steve Waldman <swa...@mc...> 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 > > |