Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
Docs Required, Release Notes Required
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.
Attachments
Issue Links
- is a child of
-
IGNITE-6980 Automatic cancelling of hanging Ignite operations
-
- Open
-
- is a parent of
-
-
- Open
-
- Is contained by
-
-
- Resolved
-
- links to
