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

Vitaliy Biryukov updated IGNITE-6527:
-------------------------------------
    Description: 
Deadlock detection works incorrectly with timeouts that haven't caused by 
deadlocks. In case of deadlok 

*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef00000, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e4200001, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b314300002, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]



  was:
*requested keys:* keys primary for the same node and blocking in sequential 
order during the timeout (or all keys that haven't locked by an optimistic 
transaction in case of near cache).

*candidates:* keys candidates to be locked on a primary node (entries contains 
in  GridDhtTxLocal). 

In the process of updating the Wait-For-Graph requested keys used as 
candidates.  But "TxDeadlock.toString" method use candidates which were 
received from messages. 

1) It causes an incorrect error message.

Example: 
K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef00000, threadId=455]
TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e4200001, threadId=456]
TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b314300002, threadId=457]

Keys:

K1 [key=6, cache=cache]
K2 [key=1, cache=cache]




> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks.
> ------------------------------------------------------------------------------------
>
>                 Key: IGNITE-6527
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6527
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Vitaliy Biryukov
>            Assignee: Vitaliy Biryukov
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of deadlok 
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef00000, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e4200001, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b314300002, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to