ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Vinogradov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-6895) TX deadlock monitoring
Date Mon, 20 Nov 2017 12:01:00 GMT

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

Anton Vinogradov commented on IGNITE-6895:
------------------------------------------

Alternative case:
Deadlock detection and timeouts are to be enforced for all transactions via grid-wide parameter.

> TX deadlock monitoring
> ----------------------
>
>                 Key: IGNITE-6895
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6895
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Anton Vinogradov
>              Labels: iep-7
>
> Deadlocks with Cache Transactions
> Description
> Deadlocks of this type are possible if user locks 2 or more keys within 2 or more transactions
in different orders (this does not apply to OPTIMISTIC SERIALIZABLE transactions as they are
capable to detect deadlock and choose winning tx). Currently, Ignite can detect deadlocked
transactions but this procedure is started only for transactions that have timeout set explicitly
or default timeout in configuration set to value greater than 0.
> Detection and Solution
> Each NEAR node should periodically (need new config property?) scan the list of local
transactions and initiate the same procedure as we have now for timed out transactions. If
deadlock found it should be reported to logs. Log record should contain: near nodes, transaction
IDs, cache names, keys (limited to several tens of) involved in deadlock. User should have
ability to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually rollback
selected transaction through web console or Visor.
> Report
> If deadlock found it should be reported to logs. Log record should contain: near nodes,
transaction IDs, cache names, keys (limited to several tens of) involved in deadlock.
> Also there should be a screen in Web Console that will list all ongoing transactions
in the cluster including the following info:
> - Near node
> - Start time
> - DHT nodes
> - Pending Locks (by request)
> Web Console should provide ability to rollback any transaction via UI.



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

Mime
View raw message