Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 24 Mar 2011 08:53:05 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <402086635.8040.1300956785792.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (DERBY-2877) Print the entire lock list when a
 deadlock occurs and deadlock tracing is on
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen resolved DERBY-2877.
---------------------------------------

    Resolution: Cannot Reproduce

Thanks, John and Kathey. I'm resolving the issue with the resolution 'Cannot Reproduce' because this deadlock cannot happen after DERBY-2991, and on the assumption that DERBY-3980/DERBY-5073 would have changed the reporting if it were reproducible.

> 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