commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kutzinski <>
Subject Re: [pool] New DBCP deadlock reported (DBCP-44)
Date Sat, 01 Mar 2008 11:21:02 GMT
As the 'inversed' locking order in evict() is obviously the source of 
the problems, I would try to avoid calling any _factory methods while 
holding the 'this' lock.

I thinking about something like this:

public void evict() {
   CursorableLinkedList tmpPool;
   Collection connsToEvict = new ArrayList();
   synchronized(this) {
     tmpPool = new CursorableLinkedList(_pool);

   // checking for conns to evict, calling methods on _factory and adding
   // conns to evict to connsToEvict

   synchronized(this) {
     // remove conns in connsToEvict from _pool
     // ignoring conns that are (currently) not in pool

Obviuosly, this doesn't work with the evictionCursor as it is 
implemented now, so it would require some work on that one.

just my 2 cents,

Phil Steitz wrote:
> Pool 1.4 has made DBCP-44 worse. The synchronization changes
> implemented to address other issues in pool 1.4 have created more
> opportunities for Evictor / client contention for locks on the pool
> and factory-related objects.  The stack trace added to DBCP-44 on
> 27-feb-08 shows a new deadlock.  That particular issue could be
> resolved by (re-)combining the last two synchronized blocks in
> addObjectToPool, but that has some performance downside and there may
> be other exposures.
> While the DBCP side of this (DBCP-44) needs work as well, I think we
> need to do something like the above to patch pool.  More eyeballs on
> this appreciated.  I will open a pool ticket to track once I have done
> some more testing.
> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message