commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Lea <ja...@kumachan.net.nz>
Subject Re: Change to DBCP pool?
Date Mon, 28 Apr 2003 22:37:48 GMT
Chris Forbis wrote:
> I would like to see how you all feel about a change I would like to see in
> the DBCP JDBC pool...
> 
>  
> 
> I would like a flag in the config that would allow for the following not to
> happen...  (I say a flag because of the time that might be needed for it,
> and if your code already does it why waste the time)
> 
>  
> 
> On connection.close(); do the check-in like it does today, but before that
> do this:
> 
>  
> 
> Get a list of all statements (of any kind) and close them, including there
> ResultSets.
> 
>  
> 
> This would allow lazy programmers ( :-) ) to not cause issues with
> Statements and ResultsSets not being closed.
> 
>  
> 
> Just an idea
> 
>  
> 
> Chris


DBCP does this already but in a different order:

1. Call Connection.close()... this is really PoolableConnection.close()
2. Connection is returned to the pool
3. The pool calls PoolableConnectionFactory.passivate()
4. The factory calls 
PoolableConnection.passivate()->DelegateConnection.passivate()
5. DelegateConnection.passivate() closes DelegateStatement and 
DelegateResultSet

I have just (yesterday) logged a bug where this is not happening in the 
following cases:

1. pool.invalidate(Connection) is used
2. The pool is set to testOnReturn and validation fails

In both these cases factory.passivate() is not called, instead the 
factory.destroyObject() method is called which closes the underlying 
connection without closing the Statements or ResultSets.

-- 
Jason Lea


Mime
View raw message