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