[jira] [Comment Edited] (IGNITE-6895) TX deadlock monitoring

["Anton Vinogradov (Jira)" <ji...@apache.org>]

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

Anton Vinogradov edited comment on IGNITE-6895 at 7/23/20, 1:26 PM:
--------------------------------------------------------------------

[~slukyanov] what is `dumpLongRunningOperations`, could you provide detailed info on what was fixed and how this solves the current issue?


was (Author: avinogradov):
[~slukyanov] what is `dumpLongRunningOperations`, could you provide detailed info what was fixes and how this solves current issue?

> 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
>
> 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)