db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Dan could you take a look at this lock manager change? Re: [jira] Updated: (DERBY-715) lock deadlocks sometimes reported as lock timeouts
Date Fri, 18 Nov 2005 03:55:47 GMT
Mike Matrigali wrote:

> While looking at Bryan's issues with DERBY-666 I think I found the
> problem that I have reported in DERBY-715.  It looks like
> deadlockWait is being used to indicate a deadlock was encountered,
> but in some cases it is false even if a deadlock was encountered.
> A question I have is if this was just a wrong use of deadlockWait,
> or if the real problem is the path through the code that sees a
> deadlock and does not set this variable.  I'd feel a little more
> confident if I understood the timing nature of the problem.
> The change here just uses the return value from the actual deadlock
> routine, which seems straight forward.  It seemed to fix the problem
> for this test case.
> I'll run the tests on this change, but was just hoping for a quick
> note to say if I was on the right track.

Looks like the right track. I think the issue is that the thread that
gets picked as the victim has already performed a deadlock check without
seeing a deadlock, so its deadlockWait is false.

So deadlockWait = true means I'm waiting and will perform a deadlock
check when I wake. It should not be used to determine if a deadlock did
occur, for that deadlockData != null is the check.

I think your fix needs the same change in other places, basically
whenever willQuiteWait is true, the code should use deadlockData and not

Nice find,


View raw message