commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe Mouawad (JIRA)" <>
Subject [jira] Updated: (DBCP-28) [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
Date Wed, 12 Jul 2006 21:20:30 GMT
     [ ]

Philippe Mouawad updated DBCP-28:


The files contain an illustration of the problem that will occur when the the previous patches
will be applied in 1.2.2:
Case 1:
The client calls isClosed() before closing a connection since commons-dbcp does not allow
double close without throwing (see
=> The problem is that since he calls isClosed, he encounters the same bug reported here
because conn.isClosed() will return true and the client will not call close.
if (!conn.isClosed())
}catch(Exception e){}
see what happens if the isClosed() in PoolableConnection returns true : ShowsLeaksIfCheckForIsClosed

The client tries to find a solution, and calls conn.close() without checking isClosed(), but
the problem is that the client is in a Persistence fwk and the client may have already called
close, so he ends up calling close() twice, see what happens if the isClosed() in PoolableConnection
returns true : ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose

So My question is, what can I do if the double close is not allowed by DBCP

> [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)
> -------------------------------------------------------------------------------
>          Key: DBCP-28
>          URL:
>      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:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message