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