-
Recent Posts
Recent Comments
- Patrick on MapCustomizer.com Launches
- Sasha Parker on MapCustomizer.com Launches
- Patrick on MapCustomizer.com Launches
- Sue Lavalli on MapCustomizer.com Launches
- adam meiklejohn on MapCustomizer.com Launches
Categories
Tags
apache beer beernutz bigbrother boston bottle buttons cartography computers conditioning css database deadlock draft economics firebug freedom gmail hexadecimal homebrewing html java javascript maps mbta mustache outlook performance podcasts politics productivity programming quality random recipe scala sea stackoverflow subway surveillance taxes tricks tv web wedding
a tip to prevent deadlocks on database connections (or, at least detect them early)
It seems there were a lot of points in our code base at work that are ripe for deadlocking on database connections. We are acquiring a connection, and then calling some other methods, and a few frames down the stack, we acquire another connection (before releasing the first). This, of course, can result in a deadlock, and it will only be detectable during PERF testing, which is always a bad time to discover a whole category of bugs in the code.
These deadlocks manifest themselves as
ConnectionWaitTimeoutException
s, with stack traces like this:So, my new trick, which I will try to use on a regular basis going forward in my everyday development, is to set a conditional breakpoint in a wrapper class that my project uses anytime it acquires a connection, so that any time a connection is opened, and there is already an open connection, it will suspend. Of course, this means that only one user can be using the app at a time, but for a local development environment, that is usually okay. You can also just reduce the size of your connection pool to 1, and see if anything blows up, but (IMHO) the breakpoint makes it easier to detect where each of the connections are coming from so you can figure out how to fix the problem.