commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [DBCP] close issues
Date Sat, 21 Jul 2007 18:14:26 GMT
On Jul 20, 2007, at 10:15 PM, Phil Steitz wrote:

> On 7/20/07, Dain Sundstrom <dain@iq80.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message