You may want to consider something like Spring's JdbcTemplate class to avoid a lot of this.
On Sunday, April 12, 2015, Shawn Heisey <[email protected]> wrote: > 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] <javascript:;> > For additional commands, e-mail: [email protected] > <javascript:;> > >
