[
https://issues.apache.org/jira/browse/DERBY-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524458
]
Knut Anders Hatlen commented on DERBY-2877:
-------------------------------------------
I looks to me that the deadlock in John's example is caused by an index split
deadlock like the one reported in DERBY-2991, only that it involves more
transaction and therefore is detected as a deadlock, not as a timeout. There is
probably an index split waiting for an X lock on (2,1), and that's what
preventing the delete transaction from obtaining a shared lock. Perhaps we
would get enough debugging information if we printed all waiters for the locks
in the cycle.
> 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.
-
You can reply to this email to add a comment to the issue online.
