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