commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: [DBCP] Apparent deadlock related to getConnection
Date Sun, 12 Apr 2015 21:02:05 GMT
On 4/12/2015 12:43 PM, Phil Steitz wrote:
> On 4/12/15 10:31 AM, Shawn Heisey wrote:
> Several methods, getSingleObject, getResultSet, closeResultSet,
> doUpdate can abandon connections on exception paths.  You should
> insert finally blocks in these methods to ensure that connections
> are closed. 

I have modified the code to put close operations in finally blocks in
getSingleObject, doUpdate, and getColumnSet, and I have done the same
thing on all uses of the other two methods, with the close method called
in a finally block.

The updated version of the Database class is here:

I've engaged in some renaming.  The getResultSet method is now called
createConnectionAndResultSet, and the closeResultSet method is now

> They don't have to be slow to deadlock, if you hit the right timing
> and the following kind of scenario:
> Thread 1 grab the lock and hold it while waiting to get a connection
> (what the thread you showed in the ticket is doing)
> Threads 2, ..., n try to get the lock before returning connections
> they hold
> Key is to get a full thread dump and see which threads are waiting
> on / holding which locks.

If the "finally" changes I've made do not fix the problem, I will gather
a new full thread dump for analysis.  You've given me an idea of some
additional bad coding that I can look for, so thank you.  I've tried to
make all synchronized code use the database in a self-contained manner,
but I might have made mistakes.


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

View raw message