Re: [dbcp] does closing a connection return an object to the pool?

[Phil Steitz]

On 9/30/13 10:54 AM, Jonathan Buhacoff wrote:
 Forgot the [dbcp] in the subject on my first post. Reposting:

 I'm using a library that accepts a DataSource as an input and automatically 
 calls getConnection() as needed and then close() on each connection when it's 
 done.

 I want to use a connection pool so I was casually looking at 
 PoolingDataSource in DBCP 1.4 to see if would work. 

 In the source code I see that PoolingDataSource.getConnection() calls 
 borrowObject() on the pool to get a new database Connection, then it wraps it 
 with PoolGuardConnectionWrapper.  But then... the close() method of 
 PoolGuardConnectionWrapper does NOT call returnObject() on the pool!  It 
 simply forwards the close() call to the delegate/wrapped Connection object.  

The delegate is a PoolableConnection.  Its close method returns it
to the pool.

 I wanted to write a quick test to see if this is really an issue or if it's 
 working and I just missed something while browsing the source code.  Looking 
 at the javadocs I noticed that GenericObjectPool needs a 
 PoolableObjectFactory to function, yet PoolableConnectionFactory requires an 
 ObjectPool in its constructor.  
PoolableConnectionFactorys need to create PoolableConnections. 
PoolableConnections need to be attached to pools so their close
methods can return them to the pool that owns them.  Therefore, PCFs
need to hold references to the object pools that manage the
connections that they create.  As you note, object pools also
require factories, so the dependency is two-way.  The PCF
constructor sets itself to be the factory for its pool.
 It seems to me that in  order to implement the PoolableObjectFactory one 
 shouldn't need a reference to the ObjectPool itself.  The pool interfaces 
 seem well defined but the DBCP implementations seem very messy. 

 Can anyone using this library confirm that it's working as expected, not 
 leaking connections?   Just wondering while I set up a test to see for myself.

Please do let us know if you find connection leaks not due do client
abandonment.

Phil

 --
 Jonathan Buhacoff
 jonat...@buhacoff.net
 --






-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[dbcp] does closing a connection return an object to the pool?

[Jonathan Buhacoff]

Forgot the [dbcp] in the subject on my first post. Reposting:

I'm using a library that accepts a DataSource as an input and automatically 
calls getConnection() as needed and then close() on each connection when it's 
done.

I want to use a connection pool so I was casually looking at PoolingDataSource 
in DBCP 1.4 to see if would work. 

In the source code I see that PoolingDataSource.getConnection() calls 
borrowObject() on the pool to get a new database Connection, then it wraps it 
with PoolGuardConnectionWrapper.  But then... the close() method of 
PoolGuardConnectionWrapper does NOT call returnObject() on the pool!  It simply 
forwards the close() call to the delegate/wrapped Connection object.  

I wanted to write a quick test to see if this is really an issue or if it's 
working and I just missed something while browsing the source code.  Looking at 
the javadocs I noticed that GenericObjectPool needs a PoolableObjectFactory to 
function, yet PoolableConnectionFactory requires an ObjectPool in its 
constructor.  It seems to me that in  order to implement the 
PoolableObjectFactory one shouldn't need a reference to the ObjectPool itself.  
The pool interfaces seem well defined but the DBCP implementations seem very 
messy. 

Can anyone using this library confirm that it's working as expected, not 
leaking connections?   Just wondering while I set up a test to see for myself.

--
Jonathan Buhacoff
jonat...@buhacoff.net
--