commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject [dbcp] Bz 33912 and testing for deadlock
Date Mon, 17 Apr 2006 03:35:00 GMT
I have reproduced the problem reported in Bz 33912, using both jdk 1.4
and 1.5 and commons-pool 1.2.  I cannot reproduce the problem when I
back the pool with commons-pool 1.3.  The fix recommended in the bug
report eliminates the deadlock when using commons-pool 1.2.

I have a couple of questions that I would appreciate others' insight on.

1.  Why does the deadlock not happen with [pool] 1.3?
2.  Why does the recommended fix solve the problem? (I guess what I am
asking here really is why exactly is the deadlock ocurring?  I have
partially validated the claim that the deadlock is due to contention
with the evictor thread, but I don't see why localizing the synch
eliminates this.  The deadlock still occurs, btw, when a statement
pool factory is provided).
3.  What is a good way to set up a Junit test that detects a deadlock?

Thanks in advance!

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message