[jira] Updated: (DBCP-28) [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)

["Phil Steitz (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/DBCP-28?page=all ]

Phil Steitz updated DBCP-28:
----------------------------

    Bugzilla Id:   (was: 33591)
    Fix Version: 1.2.2

> [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
> -------------------------------------------------------------------------------
>
>          Key: DBCP-28
>          URL: http://issues.apache.org/jira/browse/DBCP-28
>      Project: Commons Dbcp
>         Type: Bug

>     Versions: 1.2 Final
>  Environment: Operating System: All
> Platform: PC
>     Reporter: Dirk Verbeeck
>      Fix For: 1.2.2
>  Attachments: PoolableConnection.patch, TestPoolableConnection.patch
>
> Mail from Hugh Winkler on commons-dev (15-2-2005)
> --------------------------------------------------
> PoolableConnection.close() does logic equivalent to :
>   if ( isClosed()){
>       throw new SQLException(.);
>   } else {
>       _pool.returnObject(this);
>   }
> The isClosed() method is that of ancestor DelegatingConnection, and it does:
>   if(_closed || _conn.isClosed()) {
>       return true;
>   }
>   return false;
> Now nothing prevents the underlying connection from closing itself; that's
> why isClosed() checks _conn.isClosed() -- "did you close yourself while I
> wasn't looking?" But in that case PoolableConnection never calls
> _pool.returnObject(). 
> I've got a query in Oracle 10g that causes Oracle's connection to close
> itself: the famous "end of file on connection" message causes the connection
> to enter the closed state. Doesn't take long to exhaust the pool.
> I think the logic we want in PoolableConnection.close() is like so:
>   if ( _closed ){ // really ask, did *we* close the connection already
>       throw new SQLException(.);
>   } else {
>       _pool.returnObject(this);
>   }
> If I've got some logic wrong please stop me before I deploy that change
> here!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org