db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2877) Print the entire lock list when a deadlock occurs and deadlock tracing is on
Date Wed, 27 Jun 2007 14:50:25 GMT

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

John H. Embretsen commented on DERBY-2877:
------------------------------------------

Good point, it would perhaps be too much information in a system with a very large number
of users/threads/connections. Still, this information is already printed with lock wait timeouts,
which I guess occur more frequently. So I'd still like to have the possibility to get the
lock list at deadlocks too. Perhaps a new property would be in order for this? 

I considered the possibility that there is a bug in the code making the deadlock message,
but I have no idea what it could be without seeing the entire lock table at the appropriate
time. Other hints are appreciated. So far I have not been able to reproduce the deadlock outside
the long-running test, in which it seems to occur for the first time after having run for
about a week.

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


Mime
View raw message