[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-user
Subject:    [dbcp] does closing a connection return an object to the pool?
From:       Jonathan Buhacoff <jonathan () buhacoff ! net>
Date:       2013-09-30 17:54:56
Message-ID: FD6B1022-8496-46F7-A49C-AA35D34A3642 () buhacoff ! net
[Download RAW message or body]


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
jonathan@buhacoff.net
--



[prev in list] [next in list] [prev in thread] [next in thread]