On 7/21/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
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.
Agreed. Let's focus on getting dbcp 1.3 out with current (incomplete)
lifecycle semantics supported by pool 1.3 and postpone major surgery
for now. We should open a pool JIRA at some point, though,
summarizing the need for full lifecycle support.
> 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.
Its not quite that bad now; but the returning orphans do not get
closed on return. What happens now is that the GOP throws
IllegalStateException when you try to return an object (or perform any
other operation) on a closed pool. We could include a patch in pool
1.3.1 to passivate and destroy a returning orphan before throwing the
IllegalStateException, taking a baby step toward better lifeclycle
management. Since the pool does not hold references to these orphans
once its closed, I am not sure how big a problem this is in general;
though certainly for dbcp, the underlying physical connections do not
get closed right away in this case.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
