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 did attach a patch to DBCP-221 that stops BasicDataSource from
recreating the inner PoolingDataSource once close has been called.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
