[ http://issues.apache.org/jira/browse/DBCP-28?page=all ]
Philippe Mouawad updated DBCP-28:
---------------------------------
Attachment:
ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java
ShowsLeaksIfCheckForIsClosed.java
TestUtils.java
Hello,
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
http://issues.apache.org/jira/browse/DBCP-3)
=> 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())
{
try{
conn.close();
}catch(Exception e){}
}
see what happens if the isClosed() in PoolableConnection returns true :
ShowsLeaksIfCheckForIsClosed
Case2:
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: 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,
> ShowsBasicDataSourceBadNumActiveIfNoCheckForIsClosedAndDoubleClose.java,
> ShowsLeaksIfCheckForIsClosed.java, TestPoolableConnection.patch,
> TestUtils.java
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
