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

Andrey Gura commented on IGNITE-2854:
-------------------------------------

Deadlock report is improved due to removing redundant information about keys 
that aren't involved into deadlock. It looks like this:

{noformat}
Deadlock detected:

K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.
K3: TX4 holds lock, TX3 waits lock.
K4: TX2 holds lock, TX4 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=72154450, nodeOrderDrId=4, 
globalTime=1460674449052, order=1460674447948], 
nodeId=fc7e2b00-924e-48ca-83ca-e05566d000
03, threadId=737]
TX2 [txId=GridCacheVersion [topVer=72154450, nodeOrderDrId=3, 
globalTime=1460674449053, order=1460674447948], 
nodeId=32d78e43-c3c4-488b-94a6-700c1a5000
02, threadId=736]
TX3 [txId=GridCacheVersion [topVer=72154450, nodeOrderDrId=1, 
globalTime=1460674449053, order=1460674444977], 
nodeId=f54c3ddd-6e2e-46a7-b5fc-3b374e5000
00, threadId=734]
TX4 [txId=GridCacheVersion [topVer=72154450, nodeOrderDrId=2, 
globalTime=1460674449053, order=1460674447948], 
nodeId=f353a315-17da-4afd-bb03-ffc7326000
01, threadId=735]

Keys:

K1 [key=11, cache=cache]
K2 [key=1, cache=cache]
K3 [key=2, cache=cache]
K4 [key=3, cache=cache]
{noformat}

Also decreased the number of requests that need for detect deadlock. Actual 
effect depends on amount of transactions and nodes in topology. E.g. for 10 
servers, 10 clients and 10 transactions the number of requests decreased by 60%.

> Need to implement deadlock detection
> ------------------------------------
>
>                 Key: IGNITE-2854
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2854
>             Project: Ignite
>          Issue Type: New Feature
>          Components: cache
>    Affects Versions: 1.5.0.final
>            Reporter: Valentin Kulichenko
>            Assignee: Andrey Gura
>             Fix For: 1.6
>
>
> Currently, if transactional deadlock occurred, there is no easy way to find 
> out which locks were reordered.
> We need to add a mechanism that will collect information about awating 
> candidates, analyze it and show guilty keys. Most likely this should be 
> implemented with the help of custom discovery message.
> In addition we should automatically execute this mechanism if transaction 
> times out and add information to timeout exception.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to