[
https://issues.apache.org/jira/browse/IGNITE-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652189#comment-17652189
]
Denis Chudov commented on IGNITE-18043:
---------------------------------------
A quick glance how deadlock prevention works in some other databases:
- cockroach: seems there is no deadlock prevention, transaction is randomly
aborted on deadlock detection (which is working through analyzing txn wait
queue):
https://www.cockroachlabs.com/docs/stable/architecture/transaction-layer.html#txnwaitqueue
- yugabyte: DocDB exposes the ability to write provisional records which is
exercised by the query layer. Provisional records are used to order persist
locks on rows in order to detect conflicts. Provisional records have a priority
associated with them, which is a number. When two transactions conflict, the
transaction with the lower priority is aborted.
This priority is assigned randomly during transaction creation, when optimistic
concurrency control is used. For a transaction running under pessimistic
concurrency control, this priority is assigned a very high value.
https://docs.yugabyte.com/preview/architecture/transactions/explicit-locking/#concurrency-control
https://docs.yugabyte.com/preview/architecture/transactions/distributed-txns/#provisional-records
- spanner:
Spanner uses the standard "wound-wait" algorithm to handle deadlock detection.
Under the hood, Spanner keeps track of the age of each transaction that
requests conflicting locks. It also allows older transactions to abort younger
transactions (where "older" means that the transaction's earliest read, query,
or commit happened sooner).
By giving priority to older transactions, Spanner ensures that every
transaction has a chance to acquire locks eventually, after it becomes old
enough to have higher priority than other transactions. For example, a
transaction that acquires a reader shared lock can be aborted by an older
transaction that needs a writer shared lock.
https://cloud.google.com/spanner/docs/transactions#deadlock_detection
> Replaceable deadlock prevention mechanism
> -----------------------------------------
>
> Key: IGNITE-18043
> URL: https://issues.apache.org/jira/browse/IGNITE-18043
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Assignee: Denis Chudov
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation:*
> We have an embedded deadlock prevention strategy (presently, it is
> _Wait-Die_). Although, [the original
> paper|https://dl.acm.org/doi/pdf/10.1145/320251.320260] about deadlock
> prevention contains another two strategies: _priorities_ and _Wound-Wait_.
> Also, the mechanism should give a possibility to not use any strategy to
> prevent deadlock.
> All told, above shows we need to separate the prevention strategy in dedicate
> interface (which even has one implementation _Wait-Die_). Another
> implementation will be released by necessary.
> *Definition of Done:*
> A deadlock resolution strategy (_ResolutionStrategy_) has to be extracted to
> interface, which parametrizes _LockManager_. Wait-Die strategy
> (_WaitDieLockResolutionStrategy_) will be the only one implementation of
> _ResolutionStrategy_.
> _HeapLockManager_ should be parametrized by _WaitDieLockResolutionStrategy_.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
