commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [DBCP] Apparent deadlock related to getConnection
Date Wed, 22 Apr 2015 00:28:22 GMT
On 4/21/15 4:47 PM, Shawn Heisey wrote:
> On 4/14/2015 6:06 AM, James Carman wrote:
>> You may want to consider something like Spring's JdbcTemplate class to
>> avoid a lot of this.
> I don't know anything about Spring, although I didn't know anything
> about DBCP either, before I wrote this code.  I suspect that Spring is
> much larger and more complicated, though.
> Another deadlock problem has happened.
> Two separate copies of the program that both use the same MySQL database
> appear to have locked up at the same time on different hosts, using
> different JVMs.  It has been over three hours since the first "not
> updating" alarms from the watchdog thread started coming in, so this is
> definitely not a temporary deadlock.  I just barely obtained these
> stacktraces:
> Included in each of those files are the three bits of information
> requested from DBCP, which were automatically logged by the watchdog
> thread -- active, idle, and the pool objects.  That information is from
> the first alarm on each host, running a separate copy of the program.
> This time, I see no evidence of locks held by my own code.  All the
> locks present are in libraries that I am using.
> It wasn't immediately apparently to me, looking at the stacktraces,
> where the deadlock is.  I think this is different than the deadlock that
> started this thread.

Thanks for providing the full stack traces, Shawn.  I assume the
pool config is the same that you posted before, right?  Also, the
mysql driver seems to be taking initiative to try to clean up
abandoned connections itself.  That is holding some locks; but I
don't see any deadlocks in the dumps.  I will look more at this
later tonight.  I think it is possible there is a pool bug lurking
in here.  One question: are you seeing connections fail validation? 
I think you said you were testing on borrow / return.  Is that
right?  Are you just letting the pool destroy the bad ones or are
you destroying them yourself?

> Thanks,
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message