[ http://issues.apache.org/jira/browse/DBCP-65?page=comments#action_12451390 ] Sandy McArthur commented on DBCP-65: ------------------------------------
I think the only backward compatible way to fix this is to drop Pool as a dependency and pull GOP into DBCP and make it a DBCP specific implementations. This would be kinda funny since, as I understand it, Pool was birthed from DBCP long ago. The other choices would be to: 1. Extend PoolableObjectFactory with a subinterface that provides hooks for the pool's eviction thread to acquire the needed locks before acquiring the internal pool locks. I think this would be very hard to do in the existing pool implementations in a backwards compatible way, but there is the new composite pool implementation that hasn't seen an official release and we could make this work with that in Pool 2. 2. Simply make the DBCP config options that cause an eviction thread to be created be no-ops and provide a way to enable the erodingPool decorator that will be in Pool 2. 3. Perform deep surgery on DBCP so it works with existing pool implementations but, as you said, this probably won't be backward compatible and I think it's a bit of the tail wagging the dog. I personally think #2 is the best choice but I'll work with you to make #1 happen. A lot of users think they need an evictor even though I maintain that is a risky way to use Pool and should be discouraged. > [dbcp] Deadlock when evicting dbcp objects (testWhileIdle=true) > --------------------------------------------------------------- > > Key: DBCP-65 > URL: http://issues.apache.org/jira/browse/DBCP-65 > Project: Commons Dbcp > Issue Type: Bug > Environment: Operating System: All > Platform: All > Reporter: Wang Xianzhu > Fix For: 1.3 > > > The GenericKeyedObjectPool$Evictor thread has probability of deadlock with > dbcp > objects. > For example, at a certain time, a normal user thread calls a PoolingConnection > object's synchronized method, which in turn calls GenericKeyedObjectPool > object's synchronzied method. > At the same time, the evictor thread calls the GenericKeyedObjectPool object's > synchronized method 'evict', which in turn calls the PoolingConnection > object's > synchronized method. When testWhileIdle=true, the probability of evictor > calling GenericKeyedObjectPool's synchronized method is much greater. > The following is the deadlock information in the thread dump of our program > (testWhileIdle=true): > "Thread-106": > at > org.apache.commons.dbcp.AbandonedTrace.removeTrace(AbandonedTrace.java:221) > - waiting to lock <0x6a6b1b80> (a > org.apache.commons.dbcp.PoolingConnection) > at > org.apache.commons.dbcp.PoolablePreparedStatement.passivate(PoolablePreparedStatement.java:100) > at > org.apache.commons.dbcp.PoolingConnection.passivateObject(PoolingConnection.java:239) > at > org.apache.commons.pool.impl.GenericKeyedObjectPool.evict(GenericKeyedObjectPool.java:1001) > - locked <0x6a6b1858> (a > org.apache.commons.pool.impl.GenericKeyedObjectPool) > at > org.apache.commons.pool.impl.GenericKeyedObjectPool$Evictor.run(GenericKeyedObjectPool.java:1156) > at java.lang.Thread.run(Thread.java:534) > "Thread-41": > at > org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:715) > - waiting to lock <0x6a6b1858> (a > org.apache.commons.pool.impl.GenericKeyedObjectPool) > at > org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:87) > - locked <0x6a6b1b80> (a org.apache.commons.dbcp.PoolingConnection) > at > org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:185) > at > org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:278) > ... > This problem can be worked around by setting testWhileIdle to false, although > there is still very small possibility of deadlock. -- 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]
