Thread: [c3p0-users] Connections not closed after calling close()
Status: Beta
Brought to you by:
swaldman
From: Sean R. <sea...@ne...> - 2008-03-21 19:30:29
|
I am using a ComboPooledDataSource with a minimum pool size of 1. I am calling DataSources.destroy(dataSource) to close the pool. However, after this call returns, there is still an active connection to the database. It appears that the connections in the pool are not closed when the pool is closed (at least not synchronously). How can I force the pool to immediately close all connections to the database or block until they have all been closed? Thanks! |
From: Sean R. <sea...@ne...> - 2008-03-22 02:07:32
|
It seems as though there is a race-condition in the somewhere in the shutdown logic of BasicResourcePool. I added code to my application to search for the "Resource Destroyer in BasicResourcePool.close()" thread and wait until it completes. However, intermittently, the pool will acquire another connection after I have shut down the pool and the resource destroyer thread has completed. I added logging statements to the JDBC driver which logged the stack trace of the offending connection and I am certain it is from C3P0. I am intermittently seeing the following stack trace *after* the resource destroyer thread has exited. java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at net.sourceforge.jtds.jdbc.ConnectionJDBC3.<init>(ConnectionJDBC3.java:51) at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:182) at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:119) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:143) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:132) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137) at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014) at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32) at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810) at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547) BTW, I have also tried using the ScatterAcquireTask, and it did not resolve my problem. The reason I need to make absolutely sure all connections are closed is because I am trying to drop the database and it fails if there are any other connections open to the database. I would greatly appreciate anyone's help in trying to diagnose the race-condition. Thanks! ________________________________________ From: c3p...@li... [mailto:c3p...@li...] On Behalf Of Sean Rohead Sent: Friday, March 21, 2008 1:30 PM To: c3p...@li... Subject: [c3p0-users] Connections not closed after calling close() I am using a ComboPooledDataSource with a minimum pool size of 1. I am calling DataSources.destroy(dataSource) to close the pool. However, after this call returns, there is still an active connection to the database. It appears that the connections in the pool are not closed when the pool is closed (at least not synchronously). How can I force the pool to immediately close all connections to the database or block until they have all been closed? Thanks! |
From: Sean R. <sea...@ne...> - 2008-03-22 02:29:27
|
Sorry to keep responding to my own thread, but I noticed that there is a comment in the AcquireTask (line 1810) which reads as follows: //we don't want this call to be sync'd //on the pool, so that resource acquisition //does not interfere with other pool clients. BasicResourcePool.this.doAcquire(); If resource acquisition isn't synchronized with the pool, doesn't that mean that it could potentially happen either during or after the pool close operation? -----Original Message----- From: c3p...@li... [mailto:c3p...@li...] On Behalf Of Sean Rohead Sent: Friday, March 21, 2008 8:07 PM To: c3p...@li... Subject: Re: [c3p0-users] Connections not closed after calling close() It seems as though there is a race-condition in the somewhere in the shutdown logic of BasicResourcePool. I added code to my application to search for the "Resource Destroyer in BasicResourcePool.close()" thread and wait until it completes. However, intermittently, the pool will acquire another connection after I have shut down the pool and the resource destroyer thread has completed. I added logging statements to the JDBC driver which logged the stack trace of the offending connection and I am certain it is from C3P0. I am intermittently seeing the following stack trace *after* the resource destroyer thread has exited. java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at net.sourceforge.jtds.jdbc.ConnectionJDBC3.<init>(ConnectionJDBC3.java:51) at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:182) at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:119) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:143) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:132) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137) at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014) at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32) at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810) at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547) BTW, I have also tried using the ScatterAcquireTask, and it did not resolve my problem. The reason I need to make absolutely sure all connections are closed is because I am trying to drop the database and it fails if there are any other connections open to the database. I would greatly appreciate anyone's help in trying to diagnose the race-condition. Thanks! ________________________________________ From: c3p...@li... [mailto:c3p...@li...] On Behalf Of Sean Rohead Sent: Friday, March 21, 2008 1:30 PM To: c3p...@li... Subject: [c3p0-users] Connections not closed after calling close() I am using a ComboPooledDataSource with a minimum pool size of 1. I am calling DataSources.destroy(dataSource) to close the pool. However, after this call returns, there is still an active connection to the database. It appears that the connections in the pool are not closed when the pool is closed (at least not synchronously). How can I force the pool to immediately close all connections to the database or block until they have all been closed? Thanks! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ c3p0-users mailing list c3p...@li... https://lists.sourceforge.net/lists/listinfo/c3p0-users |
From: Steve W. <swa...@mc...> - 2008-03-22 04:32:02
|
Sean, c3p0 is very asynchronous. That's its thing, why it performs well under heavy concurrent load. But, it has its downsides, and you're hitting one. c3p0 close() methods are asynchronous requests to clean up resources being used by a pool. c3p0 makes (and can make) no guarantee about the timing of the cleanup. c3p0 DataSources could, and probably should, provide a mechanism that notifies or allows threads to block until all resources owned by a DataSource have in fact been closed. But that isn't implemented. Waiting for the "resource destroyer" thread in BasicResourcePool.close() is insufficient. There are other Threads around. Thus far, I wouldn't call anything a race condition... there's a feature missing, but otherwise c3p0 performs as advertised. But you may have found a race condition, I think, not because a Connection might be acquired post close(), but because at least in a quick review, I don't see where such a Connection is destroyed if acquired successfully. Somewhere post acquisition [maybe assimilateResource()], the code should check to make sure that the pool is still valid, and immediately destroy any late-acquired Connection rather than adding it to a dead pool. I think I must be missing something, because this seems like an issue that would have been detected previously. But if it's for real, it's pretty bad, and I'll fix it very soon. Another easy change that would be helpful to you would be for ScatteredAcquireTask to check that the pool is still open prior to each attempt, as it checks the forceKillAcquires() flag. That would diminish the likelihood of an acquisition actually being attempted post-close dramatically. Again c3p0 can't guarantee it'll never happen -- if a Thread is mid- acquire and you call close(), nothing's gonna stop it from getting a Connection. But c3p0 can and should guarantee that Connection is immediately destroyed. It would be nice if pools could notify clients when all resources are closed as well, but that'd be a significant feature to implement. smiles, Steve On Mar 21, 2008, at 10:29 PM, Sean Rohead wrote: > Sorry to keep responding to my own thread, but I noticed that there > is a comment in the AcquireTask (line 1810) which reads as follows: > > //we don't want this call to be sync'd > //on the pool, so that resource acquisition > //does not interfere with other pool clients. > BasicResourcePool.this.doAcquire(); > > If resource acquisition isn't synchronized with the pool, doesn't > that mean that it could potentially happen either during or after > the pool close operation? > > > -----Original Message----- > From: c3p...@li... [mailto:c3p...@li... > ] On Behalf Of Sean Rohead > Sent: Friday, March 21, 2008 8:07 PM > To: c3p...@li... > Subject: Re: [c3p0-users] Connections not closed after calling close() > > It seems as though there is a race-condition in the somewhere in the > shutdown logic of BasicResourcePool. I added code to my application > to search for the "Resource Destroyer in BasicResourcePool.close()" > thread and wait until it completes. However, intermittently, the > pool will acquire another connection after I have shut down the pool > and the resource destroyer thread has completed. I added logging > statements to the JDBC driver which logged the stack trace of the > offending connection and I am certain it is from C3P0. I am > intermittently seeing the following stack trace *after* the resource > destroyer thread has exited. > > java.lang.Exception: Stack trace > at java.lang.Thread.dumpStack(Thread.java:1206) > at > net > .sourceforge.jtds.jdbc.ConnectionJDBC3.<init>(ConnectionJDBC3.java:51) > at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:182) > at > com > .mchange > .v2 > .c3p0 > .DriverManagerDataSource.getConnection(DriverManagerDataSource.java: > 119) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:143) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:132) > at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool > $ > 1PooledConnectionResourcePoolManager > .acquireResource(C3P0PooledConnectionPool.java:137) > at > com > .mchange > .v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java: > 1014) > at com.mchange.v2.resourcepool.BasicResourcePool.access > $800(BasicResourcePool.java:32) > at com.mchange.v2.resourcepool.BasicResourcePool > $AcquireTask.run(BasicResourcePool.java:1810) > at com.mchange.v2.async.ThreadPoolAsynchronousRunner > $PoolThread.run(ThreadPoolAsynchronousRunner.java:547) > > BTW, I have also tried using the ScatterAcquireTask, and it did not > resolve my problem. > > The reason I need to make absolutely sure all connections are closed > is because I am trying to drop the database and it fails if there > are any other connections open to the database. I would greatly > appreciate anyone's help in trying to diagnose the race-condition. > > Thanks! > > ________________________________________ > From: c3p...@li... [mailto:c3p...@li... > ] On Behalf Of Sean Rohead > Sent: Friday, March 21, 2008 1:30 PM > To: c3p...@li... > Subject: [c3p0-users] Connections not closed after calling close() > > I am using a ComboPooledDataSource with a minimum pool size of 1. I > am calling DataSources.destroy(dataSource) to close the pool. > However, after this call returns, there is still an active > connection to the database. It appears that the connections in the > pool are not closed when the pool is closed (at least not > synchronously). How can I force the pool to immediately close all > connections to the database or block until they have all been closed? > > Thanks! > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users ~oo~ Steve Waldman swa...@mc... |
From: Sean R. <sea...@ne...> - 2008-03-22 14:25:48
|
Steve, Thanks for your detailed reply. With your help, I believe I have found the source of the problem and have a fix for it. In BasicResourcePool.doAcquire(), the following code checks to see if the asynchronously acquired connection should be added: synchronized(this) //assimilate resc if we do need it { msz = managed.size(); if (target_pool_size) assimilateResource(resc); else destroy = true; } I added a check to the if statement to make sure the pool had not been closed: if (!broken && msz < target_pool_size) This completely solved my problem. Once this was fixed, I actually realized that I don't need to explicitly block until the pool has finishing closing all connections -- when I execute the drop database statement, the database itself will block until all other connections have been closed. With the bug fixed, this now happens quickly after the call to pool.close(). Thanks again for all your help! Sean -----Original Message----- From: Steve Waldman [mailto:swa...@mc...] Sent: Friday, March 21, 2008 10:30 PM To: Sean Rohead Cc: c3p...@li... Subject: Re: [c3p0-users] Connections not closed after calling close() Sean, c3p0 is very asynchronous. That's its thing, why it performs well under heavy concurrent load. But, it has its downsides, and you're hitting one. c3p0 close() methods are asynchronous requests to clean up resources being used by a pool. c3p0 makes (and can make) no guarantee about the timing of the cleanup. c3p0 DataSources could, and probably should, provide a mechanism that notifies or allows threads to block until all resources owned by a DataSource have in fact been closed. But that isn't implemented. Waiting for the "resource destroyer" thread in BasicResourcePool.close() is insufficient. There are other Threads around. Thus far, I wouldn't call anything a race condition... there's a feature missing, but otherwise c3p0 performs as advertised. But you may have found a race condition, I think, not because a Connection might be acquired post close(), but because at least in a quick review, I don't see where such a Connection is destroyed if acquired successfully. Somewhere post acquisition [maybe assimilateResource()], the code should check to make sure that the pool is still valid, and immediately destroy any late-acquired Connection rather than adding it to a dead pool. I think I must be missing something, because this seems like an issue that would have been detected previously. But if it's for real, it's pretty bad, and I'll fix it very soon. Another easy change that would be helpful to you would be for ScatteredAcquireTask to check that the pool is still open prior to each attempt, as it checks the forceKillAcquires() flag. That would diminish the likelihood of an acquisition actually being attempted post-close dramatically. Again c3p0 can't guarantee it'll never happen -- if a Thread is mid- acquire and you call close(), nothing's gonna stop it from getting a Connection. But c3p0 can and should guarantee that Connection is immediately destroyed. It would be nice if pools could notify clients when all resources are closed as well, but that'd be a significant feature to implement. smiles, Steve On Mar 21, 2008, at 10:29 PM, Sean Rohead wrote: > Sorry to keep responding to my own thread, but I noticed that there > is a comment in the AcquireTask (line 1810) which reads as follows: > > //we don't want this call to be sync'd > //on the pool, so that resource acquisition > //does not interfere with other pool clients. > BasicResourcePool.this.doAcquire(); > > If resource acquisition isn't synchronized with the pool, doesn't > that mean that it could potentially happen either during or after > the pool close operation? > > > -----Original Message----- > From: c3p...@li... [mailto:c3p...@li... > ] On Behalf Of Sean Rohead > Sent: Friday, March 21, 2008 8:07 PM > To: c3p...@li... > Subject: Re: [c3p0-users] Connections not closed after calling close() > > It seems as though there is a race-condition in the somewhere in the > shutdown logic of BasicResourcePool. I added code to my application > to search for the "Resource Destroyer in BasicResourcePool.close()" > thread and wait until it completes. However, intermittently, the > pool will acquire another connection after I have shut down the pool > and the resource destroyer thread has completed. I added logging > statements to the JDBC driver which logged the stack trace of the > offending connection and I am certain it is from C3P0. I am > intermittently seeing the following stack trace *after* the resource > destroyer thread has exited. > > java.lang.Exception: Stack trace > at java.lang.Thread.dumpStack(Thread.java:1206) > at > net > .sourceforge.jtds.jdbc.ConnectionJDBC3.<init>(ConnectionJDBC3.java:51) > at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:182) > at > com > .mchange > .v2 > .c3p0 > .DriverManagerDataSource.getConnection(DriverManagerDataSource.java: > 119) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:143) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:132) > at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool > $ > 1PooledConnectionResourcePoolManager > .acquireResource(C3P0PooledConnectionPool.java:137) > at > com > .mchange > .v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java: > 1014) > at com.mchange.v2.resourcepool.BasicResourcePool.access > $800(BasicResourcePool.java:32) > at com.mchange.v2.resourcepool.BasicResourcePool > $AcquireTask.run(BasicResourcePool.java:1810) > at com.mchange.v2.async.ThreadPoolAsynchronousRunner > $PoolThread.run(ThreadPoolAsynchronousRunner.java:547) > > BTW, I have also tried using the ScatterAcquireTask, and it did not > resolve my problem. > > The reason I need to make absolutely sure all connections are closed > is because I am trying to drop the database and it fails if there > are any other connections open to the database. I would greatly > appreciate anyone's help in trying to diagnose the race-condition. > > Thanks! > > ________________________________________ > From: c3p...@li... [mailto:c3p...@li... > ] On Behalf Of Sean Rohead > Sent: Friday, March 21, 2008 1:30 PM > To: c3p...@li... > Subject: [c3p0-users] Connections not closed after calling close() > > I am using a ComboPooledDataSource with a minimum pool size of 1. I > am calling DataSources.destroy(dataSource) to close the pool. > However, after this call returns, there is still an active > connection to the database. It appears that the connections in the > pool are not closed when the pool is closed (at least not > synchronously). How can I force the pool to immediately close all > connections to the database or block until they have all been closed? > > Thanks! > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users ~oo~ Steve Waldman swa...@mc... |
From: Sean R. <sea...@ne...> - 2008-03-22 15:07:55
|
Oops. When cleaning up the code fragments, I messed up the code for the original logic. The original if statement should have been: if (msz < target_pool_size) The bug fix: if (!broken && msz < target_pool_size) Sean -----Original Message----- From: c3p...@li... [mailto:c3p...@li...] On Behalf Of Sean Rohead Sent: Saturday, March 22, 2008 8:26 AM To: Steve Waldman Cc: c3p...@li... Subject: Re: [c3p0-users] Connections not closed after calling close() Steve, Thanks for your detailed reply. With your help, I believe I have found the source of the problem and have a fix for it. In BasicResourcePool.doAcquire(), the following code checks to see if the asynchronously acquired connection should be added: synchronized(this) //assimilate resc if we do need it { msz = managed.size(); if (target_pool_size) assimilateResource(resc); else destroy = true; } I added a check to the if statement to make sure the pool had not been closed: if (!broken && msz < target_pool_size) This completely solved my problem. Once this was fixed, I actually realized that I don't need to explicitly block until the pool has finishing closing all connections -- when I execute the drop database statement, the database itself will block until all other connections have been closed. With the bug fixed, this now happens quickly after the call to pool.close(). Thanks again for all your help! Sean -----Original Message----- From: Steve Waldman [mailto:swa...@mc...] Sent: Friday, March 21, 2008 10:30 PM To: Sean Rohead Cc: c3p...@li... Subject: Re: [c3p0-users] Connections not closed after calling close() Sean, c3p0 is very asynchronous. That's its thing, why it performs well under heavy concurrent load. But, it has its downsides, and you're hitting one. c3p0 close() methods are asynchronous requests to clean up resources being used by a pool. c3p0 makes (and can make) no guarantee about the timing of the cleanup. c3p0 DataSources could, and probably should, provide a mechanism that notifies or allows threads to block until all resources owned by a DataSource have in fact been closed. But that isn't implemented. Waiting for the "resource destroyer" thread in BasicResourcePool.close() is insufficient. There are other Threads around. Thus far, I wouldn't call anything a race condition... there's a feature missing, but otherwise c3p0 performs as advertised. But you may have found a race condition, I think, not because a Connection might be acquired post close(), but because at least in a quick review, I don't see where such a Connection is destroyed if acquired successfully. Somewhere post acquisition [maybe assimilateResource()], the code should check to make sure that the pool is still valid, and immediately destroy any late-acquired Connection rather than adding it to a dead pool. I think I must be missing something, because this seems like an issue that would have been detected previously. But if it's for real, it's pretty bad, and I'll fix it very soon. Another easy change that would be helpful to you would be for ScatteredAcquireTask to check that the pool is still open prior to each attempt, as it checks the forceKillAcquires() flag. That would diminish the likelihood of an acquisition actually being attempted post-close dramatically. Again c3p0 can't guarantee it'll never happen -- if a Thread is mid- acquire and you call close(), nothing's gonna stop it from getting a Connection. But c3p0 can and should guarantee that Connection is immediately destroyed. It would be nice if pools could notify clients when all resources are closed as well, but that'd be a significant feature to implement. smiles, Steve On Mar 21, 2008, at 10:29 PM, Sean Rohead wrote: > Sorry to keep responding to my own thread, but I noticed that there > is a comment in the AcquireTask (line 1810) which reads as follows: > > //we don't want this call to be sync'd > //on the pool, so that resource acquisition > //does not interfere with other pool clients. > BasicResourcePool.this.doAcquire(); > > If resource acquisition isn't synchronized with the pool, doesn't > that mean that it could potentially happen either during or after > the pool close operation? > > > -----Original Message----- > From: c3p...@li... [mailto:c3p...@li... > ] On Behalf Of Sean Rohead > Sent: Friday, March 21, 2008 8:07 PM > To: c3p...@li... > Subject: Re: [c3p0-users] Connections not closed after calling close() > > It seems as though there is a race-condition in the somewhere in the > shutdown logic of BasicResourcePool. I added code to my application > to search for the "Resource Destroyer in BasicResourcePool.close()" > thread and wait until it completes. However, intermittently, the > pool will acquire another connection after I have shut down the pool > and the resource destroyer thread has completed. I added logging > statements to the JDBC driver which logged the stack trace of the > offending connection and I am certain it is from C3P0. I am > intermittently seeing the following stack trace *after* the resource > destroyer thread has exited. > > java.lang.Exception: Stack trace > at java.lang.Thread.dumpStack(Thread.java:1206) > at > net > .sourceforge.jtds.jdbc.ConnectionJDBC3.<init>(ConnectionJDBC3.java:51) > at net.sourceforge.jtds.jdbc.Driver.connect(Driver.java:182) > at > com > .mchange > .v2 > .c3p0 > .DriverManagerDataSource.getConnection(DriverManagerDataSource.java: > 119) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:143) > at > com > .mchange > .v2 > .c3p0 > .WrapperConnectionPoolDataSource > .getPooledConnection(WrapperConnectionPoolDataSource.java:132) > at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool > $ > 1PooledConnectionResourcePoolManager > .acquireResource(C3P0PooledConnectionPool.java:137) > at > com > .mchange > .v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java: > 1014) > at com.mchange.v2.resourcepool.BasicResourcePool.access > $800(BasicResourcePool.java:32) > at com.mchange.v2.resourcepool.BasicResourcePool > $AcquireTask.run(BasicResourcePool.java:1810) > at com.mchange.v2.async.ThreadPoolAsynchronousRunner > $PoolThread.run(ThreadPoolAsynchronousRunner.java:547) > > BTW, I have also tried using the ScatterAcquireTask, and it did not > resolve my problem. > > The reason I need to make absolutely sure all connections are closed > is because I am trying to drop the database and it fails if there > are any other connections open to the database. I would greatly > appreciate anyone's help in trying to diagnose the race-condition. > > Thanks! > > ________________________________________ > From: c3p...@li... [mailto:c3p...@li... > ] On Behalf Of Sean Rohead > Sent: Friday, March 21, 2008 1:30 PM > To: c3p...@li... > Subject: [c3p0-users] Connections not closed after calling close() > > I am using a ComboPooledDataSource with a minimum pool size of 1. I > am calling DataSources.destroy(dataSource) to close the pool. > However, after this call returns, there is still an active > connection to the database. It appears that the connections in the > pool are not closed when the pool is closed (at least not > synchronously). How can I force the pool to immediately close all > connections to the database or block until they have all been closed? > > Thanks! > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > c3p0-users mailing list > c3p...@li... > https://lists.sourceforge.net/lists/listinfo/c3p0-users ~oo~ Steve Waldman swa...@mc... ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ c3p0-users mailing list c3p...@li... https://lists.sourceforge.net/lists/listinfo/c3p0-users |