[Netarchivesuite-devel] FW: [SBForge JIRA] Commented: (NAS-1845) Database Deadlock

[Colin Rosenthal]

On 2011-04-14 11:01, Mikis Seth Sørensen wrote:
>
>
> From: Nicolas Giraud <nikokode at gmail.com <mailto:nikokode at gmail.com>>
> Reply-To: "netarchivesuite-devel at lists.gforge.statsbiblioteket.dk 
> <mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>" 
> <netarchivesuite-devel at lists.gforge.statsbiblioteket.dk 
> <mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>>
> Date: Thu, 14 Apr 2011 10:33:10 +0200
> To: "netarchivesuite-devel at lists.gforge.statsbiblioteket.dk 
> <mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>" 
> <netarchivesuite-devel at lists.gforge.statsbiblioteket.dk 
> <mailto:netarchivesuite-devel at lists.gforge.statsbiblioteket.dk>>
> Subject: Re: [Netarchivesuite-devel] FW: [SBForge JIRA] Commented: 
> (NAS-1845) Database Deadlock
>
>     Hi Colin and Mikis,
>
>     I have uploaded a patch NAS-1845, that solves the particular
>     avatar of the issue I had. As I suspected, it would seem that
>     Derby might detect deadlocks if the same thread opens several
>     connections. However in this example, I don't understand why a
>     deadlock happens, as we don't access the same tables in the nested
>     DAO method (HarvestDefinitionDBDAO#getSparseDomainConfigurations)
>     and the top-level call (HarvestDefinitionDBDAO#flipActive).
>
>     Can you guys have a look at this?
>
>     Currently I see two options to fix this:
>
>     1) refactor all DAO classes to make sure that only top-level DAO
>     calls (i.e. called from JSPs) request a connection from the pool,
>     and that all nested call reuse the same connection. That's
>     probably a tad tedious and painful, but would enhance the code.
>
> How long do you think a quick first step refactoring would require?
>
>
>     2) modify HarvestDBConnection to ensure that a same thread cannot
>     have more than one connection opened at a time
>
> I guess the way of ensuring this would not happen be to throw a 
> RuntimeException, which might give us clearer idea of what is going 
> on, but still crash/stop the application.
Hi Nicolas,

It should be possible to do this using a ThreadLocal connection. There 
is a (non-generic) example of how to this at
http://www.ibm.com/developerworks/java/library/j-threads3/index.html.

Do you have experience with ThreadLocal? It's new to me, but it looks 
like the right idea. The only thing that worries us is how to ensure 
that the
Connection is closed when the ThreadLocal<Connection> instance is ready 
for garbage collection.

cheers,
Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/netarchivesuite-devel/attachments/20110414/1d62588f/attachment-0002.html>