You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Maxim Muzafarov (Jira)" <ji...@apache.org> on 2019/09/24 11:48:00 UTC

[jira] [Commented] (IGNITE-6895) TX deadlock monitoring

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

Maxim Muzafarov commented on IGNITE-6895:
-----------------------------------------

Folks, I've removed 2.8 label due to the issue inactivity

> TX deadlock monitoring
> ----------------------
>
>                 Key: IGNITE-6895
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6895
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Anton Vinogradov
>            Assignee: Dmitriy Sorokin
>            Priority: Major
>              Labels: iep-7
>             Fix For: 2.8
>
>
> 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
(v8.3.4#803005)