On 4/12/2015 12:43 PM, Phil Steitz wrote: > On 4/12/15 10:31 AM, Shawn Heisey wrote: >> http://apaste.info/6pX > > 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: http://apaste.info/6XU I've engaged in some renaming. The getResultSet method is now called createConnectionAndResultSet, and the closeResultSet method is now closeAllFromResultSet. > 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. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
