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.
