commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [DBCP] Release 1.3 soon?
Date Fri, 20 Jul 2007 18:26:42 GMT
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote:

> On 7/19/07, Dain Sundstrom <> 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 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 :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message