On Jul 20, 2007, at 10:15 PM, Phil Steitz wrote:
On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
I think this will require a patch to pooling (documented in
DBCP-221). What are the plans for pooling? This is a tiny change so
we could do a pool 1.3.1 or 1.4 release. Alternatively, we could
wait until DBCP 1.4 (and the next pool release) to address this
issue.
I am fine waiting to DBCP 1.4, since unless we are talking about
different things, this really amounts to a significant change to both
dbcp and pool. If what we want is to *always* track open connections
and have the "lingering close" apply to the active (i.e. checked out)
as well as idle connections, we need to follow through on what looks
like it was the original plan of moving AbandonedObjectPool to pool
and use this _all the time_ in place of GenericObjectPool, which is
really just an idle object pool (maintains no references to borrowed
objects).
I think there are two features here also. The first is a lingering
close where we close the data source along with all idle connection.
Then as the checked out connections are returned to the pool, we
destroy them instead of putting them in a closed pool. The second
feature is a force close which as you pointed out requires tracking
of active connection. After looking at the pooling code, I think
that will take a lot of work to implement with the current code.
In any case, we need to get a pool release out ASAP since pool 1.3
introduced some bugs that are causing problems (see for example
POOL-97) since dbcp started using this version. Synchronization was
increased in pool 1.3 as well. The hang here is lack of volunteer
time and difficulty getting into the codebase. I have only recently
started working on the pool code base. The compositepool package
includes an alternative impl that we have been thinking about as a
pool 2.0.
The plan that I proposed a while back
(http://www.mail-archive.com/commons-dev@jakarta.apache.org/
msg94027.html)
was to push out a pool 1.3.1 patch release fixing POOL-97 (when
reviewing the patch there, remember that dbcp statement pooling can
create quite a few pools) and other bugs fixed since 1.3 and have DBCP
1.3 depend on that, both fully backward compatible with current
versions. I still think we should do that. I can handle the RM duty
for both of these and close a couple more of the pool bugs, but what
we need to speed things up is more eyeballs validating and testing and
contributing - and applying - patches.
I'll try to review the patch. If we do do a 1.3.1, I think we should
change GOP and GKOP to destroy objects returned to the pool after the
pool is closed. Otherwise you end up with stuck objects in a closed
pool.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
