[
https://issues.apache.org/jira/browse/DERBY-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010219#comment-13010219
]
Knut Anders Hatlen commented on DERBY-2877:
-------------------------------------------
Hi Kathey,
I think this issue was logged to get a dump of the lock table, not a thread
dump.
My understanding was that the need for this was triggered by a bug in Derby's
deadlock detection/reporting that caused some deadlocks to be reported without
enough information to tell what had deadlocked, like the deadlock in the issue
description. The printed deadlock cycle clearly isn't a cycle, so either the
full cycle wasn't printed, or the deadlock error was a false positive.
If the underlying bug is fixed so that deadlock errors always report all locks
involved in the deadlock, there should be no need to dump the full lock table
on a deadlock. The deadlock error message is supposed to show information about
all involved locks and be self-sufficient. We don't know if the underlying bug
is fixed, since we don't have a repro, but there is a possibility that it has
the same root cause as DERBY-3980 and DERBY-5073.
> 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
