[
https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-6895:
-------------------------------------
Description:
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.
> Provide metric to monitor any TX deadlock
> -----------------------------------------
>
> 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)
