[
https://issues.apache.org/jira/browse/DBCP-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13709976#comment-13709976
]
Phil Steitz commented on DBCP-398:
----------------------------------
Consensus on the dev list [1] is that we should *not* change the isClosed
contract. Client code should not test isClosed before returning a connection
and should not rely on properties of the connection handle once a connection
has been returned. Javadoc will be updated, but we are not going to change the
implementation. The simple workaround is not to test isClosed before returning
the connection to the pool.
[1] http://markmail.org/thread/qzevcticenh7cabx
> DBCP hangs on common pool borrowObject when PoolableConnection is used and
> the underlying connection closed unexpectedly (connection resets/timouts)
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DBCP-398
> URL: https://issues.apache.org/jira/browse/DBCP-398
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2, 1.3, 1.4, 2.0
> Reporter: Sarvesh Sakalanaga
> Attachments: DBCP-398.0.patch
>
>
> The bug is in org.apache.commons.dbcp.PoolableConnection as isClosed method
> on this calls super.isClosed which returns true (as
> DelegatingConnection::isClosed { _closed || _conn.isClosed() }). Since
> PoolableConnection needs to release objects to pool even if the underlying
> connection is closed the isClosed method should be overridden in this class
> and should return _closed. This _closed is the delegating connection close
> which will be set to false even if the underlying connection is closed
> (_conn.isClosed). The fix should also not throw on PoolableConnection::Close
> method if underlying connection is closed as this state is a valid state and
> is expected.
> Also currently the way it stands the clients of PoolableConnection will/may
> not call Close() as isClosed always returns true in this case.
> Below is the stack that the thread hangs on:
> ◾waiting on <0x00000007b5a50e48> (a
> org.apache.commons.pool.impl.GenericObjectPool$Latch)
> at java.lang.Object.wait(Object.java:503)
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1104)
> ◾locked <0x00000007b5a50e48> (a
> org.apache.commons.pool.impl.GenericObjectPool$Latch)
> at
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)
> at
> org.datanucleus.store.rdbms.ConnectionProviderPriorityList.getConnection(ConnectionProviderPriorityList.java:57)
> at
> org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getConnection(ConnectionFactoryImpl.java:354)
> at
> org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.getXAResource(ConnectionFactoryImpl.java:314)
> at
> org.datanucleus.store.connection.ConnectionManagerImpl.enlistResource(ConnectionManagerImpl.java:386)
> at
> org.datanucleus.store.connection.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:252)
> at
> org.datanucleus.store.connection.AbstractConnectionFactory.getConnection(AbstractConnectionFactory.java:60)
> at
> org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:449)
> at
> org.datanucleus.store.AbstractStoreManager.getConnection(AbstractStoreManager.java:418)
> at
> org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:595)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
