[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222229#comment-15222229
]
Andrey Gura edited comment on IGNITE-2854 at 4/1/16 7:45 PM:
-------------------------------------------------------------
Algorithm described in previous comment has one drawback: it can't detect
deadlock for transaction that was timed out and involved into deadlock or can
detect invalid deadlock due to a race conditions.
For example we have transactions {{TX1}} and {{TX2}} with the same timeout and
start time. {{TX1}} holds lock on key {{K1}} and requests lock for {{K2}} while
{{TX2}} hold lock on key {{K2}} and requests lock for {{K1}} so it is deadlcok.
{{K1}} and {{K2}} have different primary nodes so both transactions are
distributed.
When {{TX1}} and {{TX2}} times out all {{GridDhtColocatedLockFuture}} and
blocked {{GridDhtLockFuture}} times out also. {{GridDhtLockFuture.onTimeout}}
initiates deadlock detection while {{GridDhtColocatedLockFuture.onTimeout}}
releases locks and then rollback corresponding transaction. So we have
incomplete information about transactions state and can't detect deadlock or
detect something invalid like {{TX1 <-> TX1}}.
was (Author: agura):
Algorithm described in previous comment has one drawback: it can't detect
deadlock for transaction that was timed out and involved into deadlock or can
detect invalid deadlock due to a race conditions.
For example we have transactions {{TX1}} and {{TX2}} with the same timeout and
start time. {{TX1}} holds lock on key {{K1}} and requests lock for {{K2}} while
{{TX2}} hold lock on key {{K2}} and requests lock for {{K1}} so it is deadlcok.
{{K1}} and {{K2}} have different primary nodes so both transactions are
distributed.
When {{TX1}} and {{TX2}} times out all {{GridDhtColocatedLockFuture}} and
blocked {{GridDhtLockFuture}} times out also. {{GridDhtLockFuture.onTimeout}}
initiates deadlock detection while {{GridDhtColocatedLockFuture.onTimeout}}
releases locks and then rollback corresponding transaction. So we have
incomplete information about transactions state.
> 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)
