[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15270549#comment-15270549 ] Andrey Gura commented on IGNITE-2854: - Merged into master branch. > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15251958#comment-15251958 ] Andrey Gura commented on IGNITE-2854: - Done. > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15251374#comment-15251374 ] Semen Boikov commented on IGNITE-2854: -- I reviewed last changes, did some changes, please take a look. Have some more comments: - after you changed 'directType' for messages code in DeadlockDetectionListener.processFailedMessage is broken, please fix and add test - let's add sanity check in tests that IgniteTxManager.deadlockDetectFuts on all nodes is empty at the end > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15250072#comment-15250072 ] Semen Boikov commented on IGNITE-2854: -- Some more comments: - need add proper synchronization for TxDeadlockFuture.curNodeId access - please change TxDeadlockFuture.futId from IgniteUuid to Long - please add some basic test for deadlock exception messsage (check correctness of info about keys' values, nodes, threads) > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248396#comment-15248396 ] Andrey Gura commented on IGNITE-2854: - Done. Also added tests. > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245244#comment-15245244 ] Semen Boikov commented on IGNITE-2854: -- Andrey, I have comments regarding TransactionDeadlockException: - it should be placed in 'org.apache.ignite.transactions' package and extend IgniteException, also please add some javadoc explaining when it can be thrown - we need to add it in 'throws' clause and javadoc for all org.apache.ignite.transactions.Transaction's, IgniteCache methods where it can be thrown. I also see that others transactions exceptions (TransactionTimeoutException, TransactionRollbackException, TransactionOptimisticException, TransactionHeuristicException) are not declared in 'throws' and javadoc, please fix it as well as part of this ticket. > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244850#comment-15244850
]
Andrey Gura commented on IGNITE-2854:
-
Added the following system properties:
* {{IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT}} - allows limit deadlock detection
time.
* {{IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS}} - allows limit the number of
iteration for performing deadlock detection (0 or less means that deadlock
detection disabled).
Simplified asynchronous request/response processing.
Added message processing in case of unmarshalling errors.
> 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=146067977],
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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236153#comment-15236153
]
Andrey Gura commented on IGNITE-2854:
-
Deadlock report improved and looks like:
{noformat}
Deadlock detected:
K5: TX1 holds lock, [TX4] wait lock.
K1: TX2 holds lock, [TX1] wait lock.
K7: TX3 holds lock, [TX2] wait lock.
K14: TX4 holds lock, [TX3] wait lock.
Transactions:
TX1 [txId=GridCacheVersion [topVer=71893606, nodeOrderDrId=4,
globalTime=1460413605747, order=1460413604719],
nodeId=37bff732-e1a1-4e7b-8df9-dc565883, threadId=620]
TX2 [txId=GridCacheVersion [topVer=71893606, nodeOrderDrId=1,
globalTime=1460413605747, order=1460413601448],
nodeId=1dad-e670-4ab8-b726-d4d36660, threadId=617]
TX3 [txId=GridCacheVersion [topVer=71893606, nodeOrderDrId=2,
globalTime=1460413605748, order=1460413604719],
nodeId=1de6fe2c-f5a8-4e97-8433-9bfdaee1, threadId=619]
TX4 [txId=GridCacheVersion [topVer=71893606, nodeOrderDrId=3,
globalTime=1460413605749, order=1460413604719],
nodeId=f8ab43fa-8859-4aad-9b89-1594c972, threadId=618]
Keys:
K1 [key=1, cache=cache]
K2 [key=136, cache=cache]
K3 [key=137, cache=cache]
K4 [key=411, cache=cache]
K5 [key=11, cache=cache]
K6 [key=479, cache=cache]
K7 [key=2, cache=cache]
K8 [key=275, cache=cache]
K9 [key=274, cache=cache]
K10 [key=273, cache=cache]
K11 [key=337, cache=cache]
K12 [key=342, cache=cache]
K13 [key=341, cache=cache]
K14 [key=3, cache=cache]
K15 [key=350, cache=cache]
K16 [key=343, cache=cache]
K17 [key=408, cache=cache]
{noformat}
Need to remove redundunt keys from report and add tests/
> 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233174#comment-15233174
]
Andrey Gura commented on IGNITE-2854:
-
Removed redundant messages for synchronization awaiting for finishing of
deadlock detection. {{GridDhtLockFuture}} just doesn't release locks on
{{onTimeout}} invocation. Locks will be release during transaction rolling back.
Detection process is asynchronous now and doesn't block any thread.
It makes sense to implement detection for near cache and optimistic
transactions separately. Created IGNITE-2968 and IGNITE-2969.
> 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1529#comment-1529
]
Andrey Gura commented on IGNITE-2854:
-
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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15220558#comment-15220558
]
Andrey Gura commented on IGNITE-2854:
-
Algorithm is changed in order to limit amount of requested info on keys basis:
# When {{GridDhtLockFuture}} is timed out we run deadlock detection. As input
we have near transaction ID and pending keys that wasn't locked by this
transaction.
# Deadlock detector maps pending keys on primary nodes (on first step it is
always current node). As results deadlock detector have set of candidates
represented by pairs {{UUID -> List}}
# For each candidate (if exists) deadlock detector send request to node by its
{{UUID}}. Request contains keys from candidates pairs. If thre is no candidate
process finishes.
# Selected candidate removed from candidate set, node and all keys marked as
handled.
# Node processes request and returns all mvcc candidates that hold or waiting
for *passed keys* and all other keys involved into transactions that associated
with found mvcc candidates.
# Deadlock detector builds wat-for-graph (or updates it) and tries to find
cycle on it using input transaction ID as first vertex of graph.
# If cycle is found then deadlock detection stops (deadlock found).
# If cycle isn't found then deadlock detector maps obtained keys to primary
nodes and near nodes. Candidates set is updated.
# Process continues from step 3
Properties of this implementation:
* Always will found at most one deadlock for given timed out transaction.
* Always will detect deadlock which cause an user transaction timeout (if
exist). Step 6.
* Detection will finish as soon as possible because after each update of
wait-for-graph it can find deadlock.
* Detection minimize the network utilisation. Step 5.
Implementation requires some test coverage for different cases:
* Different nodes that start deadlocked transaction (all from one
(clinet/server), all from different (client/server), mix)
* Different nodes that start transaction with timeout (server/client near node,
server/client non near node)
* More then one cycle (waiting for each other or independent)
* Transitive transactions waiting for each other and eventually waiting for
deadlocked transaction.
Problems to be solved:
* Deadlock detector behaviour in case of topologu changes and transactions
remapping.
* Deadlock detector behaviour in case of remote request failed.
> 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217090#comment-15217090 ] Andrey Gura commented on IGNITE-2854: - At this moment search of the first deadlock (cycle in wait-for-graph) implemented as `DeadlockDetection` class that used by `IgniteTxManager`. Messaging implemented via `GridIoManager` and new `TOPIC_TX` topic. If deadlock detected then detector prints out transaction IDs that involved into deadlock and keys that cause of deadlock. Need to extend current algorithm for finding all possible deadlocks for active near transactions on current node. At the same time detection have to request from remote nodes only transactions that contain the same keys as transactions on the local node. It allows to reduce network traffic but increases possible requests in cases when deadlock wasn't detected. Also need to find out better way for reporting found deadlocks. > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214519#comment-15214519 ] Alexey Goncharuk commented on IGNITE-2854: -- The approach sounds good. However, I would leave the option to automatically rollback the oldest transaction in a deadlock to be configured - in some cases it makes sense to only rollback such transactions from a management tool. > 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)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15210403#comment-15210403
]
Andrey Gura commented on IGNITE-2854:
-
*Suggested solution:*
# Tx manager executes deadlock detection procedure (if enabled) in the
following cases:
** On Tx timeout (if enabled)
** On request (e.g. MBean)
** Periodically (if period configured)
# Choosing Tx candidate for deadlock detection:
** In case of deadlock detection triggered by Tx timeout then timed out Tx will
be choosen.
** Otherwise get oldest Tx.
# Deadlock detection
** For chosen Tx get all cache entries ({{IgniteTxEntry}} instances) that
involved into Tx.
** Each Tx entry contains node Id on which lock request sent. So deadlock
detector has Ids of all nodes involved into Tx.
** Request Tx snapshot from all involved nodes if needed (Tx can involve only
local node) and merge it with local Tx snapshot. _*Note:*_ _It makes sense
retrieve Tx snapshot that contains only Txs that involve known Tx entries in
order to reduce network traffic._
** If resulting Tx snapshot involves other nodes then request Tx snapshots from
that nodes and merge all snapshot with resulting snapshot. _*Note:*_ _Actually
we can first try to detect deadlock on current Tx snapshot and request Tx
snapshots from other remote nodes only if deadlock isn't found._
** Build _resource allocation graph_ from {{GridCacheMvcc}}'s local candidates
(owner candidate - lock aquired, not owner candidate - lock requested) and
reduce it to _wait for graph (WFG)_.
** Try to find cycle in WFG.
** If cycle is found the deadlock detected
** otherwise choose another Tx candidate that is still not involved in deadlock
detection procedrue and repeat whole procedure. _*Note:*_ _Repetition is
redundant in cases when deadlock detection was triggered by Tx timout._
# Deadlock resolving (if configured)
It makes sense to rollback oldest Tx involved into detected deadlock.
Especially for cases when Tx timout isn't defined.
> 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)
