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,
Christoph
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
