Dan could you take a look at this lock manager change? Re: [jira] Updated: (DERBY-715) lock deadlocks sometimes reported as lock timeouts

[Mike Matrigali <mi...@sbcglobal.net>]

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.

Mike Matrigali (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-715?page=all ]
> 
> Mike Matrigali updated DERBY-715:
> ---------------------------------
> 
>     Attachment: derby715.diff
> 
> I have not  run tests on this diff yet, just posting to get some input on whether I am on the right track or not.  Do not commit this patch until I have had a chance to get it reviewed and run tests.
> 
> 
>>lock deadlocks sometimes reported as lock timeouts
>>--------------------------------------------------
>>
>>         Key: DERBY-715
>>         URL: http://issues.apache.org/jira/browse/DERBY-715
>>     Project: Derby
>>        Type: Bug
>>  Components: Services
>>    Versions: 10.0.2.0
>>    Reporter: Mike Matrigali
>>    Assignee: Mike Matrigali
>>    Priority: Minor
>>     Fix For: 10.2.0.0
>> Attachments: derby715.diff, repro.java
>>
>>Sometimes a lock deadlock is reported as a lock timeout, even when the software has done a deadlock search and found it to be a deadlock.
> 
> 

Re: Dan could you take a look at this lock manager change? Re: [jira] Updated: (DERBY-715) lock deadlocks sometimes reported as lock timeouts

[Daniel John Debrunner <dj...@debrunners.com>]

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
deadlockWait.

Nice find,
Dan.




Dan.
>