[
https://issues.apache.org/jira/browse/IGNITE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16597270#comment-16597270
]
Ivan Pavlukhin commented on IGNITE-9411:
----------------------------------------
Locks are handled similarly for following SQL statements: {{INSERT, MERGE,
UPDATE, DELETE, SELECT ... FOR UPDATE}}. Here is the procedure:
_Check if row is already locked. If locked wait lock release. Otherwise place
own lock. Locks are released upon transaction end._
Lock waiting should support timeout. If timeout exceeds transaction should be
marked _rollback-only_. Timeout can be specified per statement or per
transaction.
> Lock: make sure lock timeouts works fine
> ----------------------------------------
>
> Key: IGNITE-9411
> URL: https://issues.apache.org/jira/browse/IGNITE-9411
> Project: Ignite
> Issue Type: Task
> Components: mvcc
> Reporter: Vladimir Ozerov
> Assignee: Ivan Pavlukhin
> Priority: Major
> Fix For: 2.7
>
>
> In SQL it is not uncommon that locks are taken in arbitrary order, what may
> lead to deadlocks. Fair deadlock detector is good solution in monolithic
> databases - just analyze dependency graph and kill one of conflicting
> transactions.
> We have a ticket to implement distributed deadlock detector in Ignite [1].
> However, this solution is rather complex and may bring some overhead.
> For now it is better to rely on some timeout (global or per-transaction), and
> rollback TX when it fails to lock certain entry for a long time. Probably we
> already have this feature in some form. Need to add verify that it works and
> add more tests if needed.
> [1] https://issues.apache.org/jira/browse/IGNITE-9322
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
