commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject [DBCP] close issues
Date Sat, 21 Jul 2007 00:29:29 GMT
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 <dain@iq80.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message