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
|