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.
<snip/>
I would love to have a fix for DBCP-44; but that could wait on pool
1.4 if necessary (and Ipersonally see no way to fix it just within
dbcp. It would be great if I was wrong on that).
I think the makeObject method is over synchronized. Actually, the
class doesn't look it's synchronized properly at all. I'll take a
shot at fixing this.
We should also address DBCP-4 (by using jdk logging, since we have
bumped to 1.4 level). I think it would be good to start adding some
simple instrumentation in 1.3 that we could add to in subsequent
releases. Having things like physical connection opens / closes, pool
high water marks, waits, etc., loggable would make debuggng and
performance tuning much easier.
In the future, I'd like these events to be available via a listener
interface, so I can write monitoring code (like an mbean). Of course
working out that interface takes time, so I think we should add the
logging in 1.3 and a listener in 1.4.
Are there any notes on how we'd like to use util.Logging (log names,
levels, etc.)?
I will finish reviewing recent patches tomorrow and come up with a
straw man release plan this weekend if no one beats me to it.
I'll look at DBCP-44 since I think it is an easy small fix. Then the
close() issue and finally logging, unless someone beats me to them.
BTW, it is getting challenging to write new patches with the current
patches I have out. I have been trying to keep patches so there
aren't file overlaps. I may need to start putting ordering
information into the patches like apply after DBCP-1234.
Thanks for all of your help on this, Dain.
No prob. This code is like programming crack for me.... Small tasks
for a big programming high :)
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
