commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19374] New: - Potential for DelegateStatement, DelegateResultSet to be left open
Date Sun, 27 Apr 2003 23:10:56 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19374>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19374

Potential for DelegateStatement, DelegateResultSet to be left open

           Summary: Potential for DelegateStatement, DelegateResultSet to be
                    left open
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Dbcp
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: jason@kumachan.net.nz


There is a potential for DBCP to leave DelegateStatement and DelegateResultSet
open when PoolableConnection is closed.

PoolableConnection overrides DelegateConnection.close() method and returns the
object to the pool.  The pool will normally call
PoolableConnectionFactory.passivate() which in turn calls
DelegateConnection.passivate() that closes any open DelegateStatement and
DelegateResultSet.

When a pool is set up to testOnReturn and the validation fails, then passivate()
is not called, only factory.destroyObject() is called.  Also if a connection is
returned with pool.invalidateObject() then factory.destroyObject() is only called.

factory.destroyObject() just calls PoolableConnection.reallyClose() which closes
the underlying connection and does not close any DelegateStatements and
DelegateResultSets created.

Obviously PoolableConnection.close() should override DelegateConnection.close()
because the latter closes the underlying connection which we don't want to have
happen.  It is relying on the pool to call passivate() when the object is
returned to the pool, so it doesn't need to call passivate() itself.

Solutions?

Perhaps PoolableConnectionFactory.destroyObject() should call
DelegateConnection.passivate()?

Perhaps PoolableConnection.close() should use the
PoolableConnectionFactory.passivateObject() code, and PoolableConnectionFactory.
be modified to do nothing?  This would return a clean connection back to the pool.

I thought GenericObjectPool might have been at fault but I think it seems
reasonable for the pool to not passivate() and object and only call
factory.destroyObject() and have it clean everything up.

---------------------------------------------------------------------
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