[jira] [Commented] (DERBY-2877) Print the entire lock list when a deadlock occurs and deadlock tracing is on

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010119#comment-13010119 ] 

Knut Anders Hatlen commented on DERBY-2877:
-------------------------------------------

If we'd had a way to reproduce this deadlock, it would have been interesting to see if the fix for DERBY-3980 and DERBY-5073 changed how it was reported. One of the problems fixed there was that a deadlock could sometimes be detected prematurely, before the the full cycle had been seen. The observed consequence of that problem was that the transactions involved in the deadlock never agreed on which transaction to abort, because none of the transactions thought they were involved in the deadlock themselves. I'm wondering, though, if it could also result in incomplete cycles being reported, like the one in this bug report. But I haven't been able to reproduce such a deadlock to see for myself.

The deadlock in the bug report is caused by the index split problems fixed in DERBY-2991, so the exact same deadlock won't happen again on trunk or any recent releases. Since we don't have a repro for a deadlock where printing the entire lock table would be useful in diagnosing the deadlock, and since we've fixed problems in the deadlock detection algorithm that may have changed how these deadlocks are reported, would it make sense to resolve this issue as "Cannot Reproduce"? If a deadlock with an incomplete cycle in the error message ever occurs again, we can reopen this issue or file a new bug report.

> Print the entire lock list when a deadlock occurs and deadlock tracing is on
> ----------------------------------------------------------------------------
>
>                 Key: DERBY-2877
>                 URL: https://issues.apache.org/jira/browse/DERBY-2877
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions: 10.2.2.0
>            Reporter: John H. Embretsen
>
> When a deadlock occurs, derby includes the cycle of locks which caused the deadlock in the SQLException message. This is also printed to derby.log if the properties derby.locks.deadlockTrace and derby.locks.monitor are set to true, or if debug code is being used (e.g. jars from lib-debug distributions). It will be easier to debug deadlocks if the entire lock table is printed to derby.log as well (alternatively to both derby.log and the exception message) in these cases. An example of such a lock table is available at http://wiki.apache.org/db-derby/LockDebugging.
> For example, in a long-running test I have observed deadlocks with lock cycle messages such as:
> Lock : ROW, DELETED, (2,1)
>   Waiting XID : {6241401573, S} , U1, DELETE FROM "U1"."DELETED" WHERE CURRENT OF "SQL_CURLH000C9"
>   Granted XID : {6241401662, S} 
> Lock : ROW, DELETED, (3,3523)
>   Waiting XID : {6241401662, U} , U1, SELECT ITEMID FROM DELETED
>   Granted XID : {6241401573, U} 
> . The selected victim is XID : 6241401573.
> It is not clear from this output why XID 6241401573 is waiting for a shared lock (S) on row (2,1), as an S lock is compatible with other S locks [1]. 
> Having a snapshot of the contents of the lock table at the time of the deadlock would probably help a great deal in the debugging process. 
> [1]: Lock compatibility: http://db.apache.org/derby/docs/dev/devguide/rdevconcepts2462.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira