On 7/20/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote:
> On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:
>
>> On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>>> Are there any DBCP-1.3 release plans? Based on the JIRAs I think we
>>> are close to being ready to release. Are there any items that are
>>> planned but don't have JIRAs?
>>
>> There are two things that I would like to at least talk about that
>> relate to various JIRAs and comments on the list:
>>
>> 1) Intended current and future contract of close() on a connection
>> pool, in particular the contract of BasicDataSource.close. The
>> javadoc says "Close and release all connections that are currently
>> stored in the connection pool associated with our data source." Some
>> users interpret this - incorrectly - to mean that close will close
>> *active* as well as idle connections. Even when AbandonedConfig is
>> used (in which case the pool holds references to connections that
>> have
>> been checked out), close only closes idle connections (since the
>> "pool" is really and idle object pool). So the answer to the
>> question
>> in, e.g. DBCP-221, is "sorry, no way to do that." Javadoc should be
>> improved in any case.
>>
>> 2) Immutable-once-initialized status of BasicDataSource. I am
>> inclined to close DBCP-221 as WONTFIX, but in this case we should
>> rip out the remnants of what must have seemed like a good idea at the
>> time to support "restart". This is sort of related to 1), because if
>> we are going to attempt to allow BasicDataSource to be mutable
>> once it
>> has been initialized, I don't see any way to do that consistently
>> without closing or appropriately modifying connections that have been
>> checked out. Since we don't do that now, we can't really support
>> this. My vote would be to keep BasicDataSource
>> "immutable-once-initialized".
>
> I think these are basically the same issue. I agree with the
> comments in DBCP-221 which seems to want a lingering close. This
> is in line with how I expect close to work (having not read any of
> the pooling code yet).
>
> I think the root of this problem is we don't have a clear start/
> stop life-cycle methods. Currently, we are using the first
> getConnection() for start and close() for stop, which I think are
> good choices. Maybe we could keep those choices, and introduce an
> explicit start(), stop() and stop(long maxWait). This way we can
> support the close lingering and close immediately options people
> seem to be asking for. Once we have this functionality, it should
> be easy to add restart() which would close() lingering the existing
> inner datasource and create/start a new one.
>
> I'm not sure this is something that can be done without changes to
> pool, but I'll take a look at it today.
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).
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.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
