[
https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644484#comment-17644484
]
Vladislav Pyatkov commented on IGNITE-18294:
--------------------------------------------
Merged 92466d5bfce5f6a7efe2d4d6a744c6f67b56d48f
> Multiple lock intentions support
> --------------------------------
>
> Key: IGNITE-18294
> URL: https://issues.apache.org/jira/browse/IGNITE-18294
> Project: Ignite
> Issue Type: Bug
> Reporter: Denis Chudov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Current implementation of HeapLockManager relies on waiters that can support
> only one lock intention for each transaction at a moment of time. This can
> lead to problems like following:
> - there are transactions tx1, tx2, tx3 started in corresponding order;
> - all txs acquire S-locks;
> - tx2 tries to acquire IX-lock, it's incompatible with S-locks from tx1 and
> tx3, this is a lock intention and a future is created, which is completed
> when SIX-lock is acquired (supremum of S and IX locks)
> - tx2 concurrently tries to acquire X-lock, this is another lock intention,
> supremum of locks for tx2 is X-lock. The information about previous intention
> is lost;
> - tx3 is committed, and tx2 waits only for tx1 but it is not allowed to wait
> for it due to wait-die deadlock prevention. All lock intentions should be
> canceled.
> Definition of done:
> We have lock mode counters inside of waiter, they should be adapted for lock
> intention support. Also, "upgraded" flag of waiters and all the logic related
> to "previous lock mode" should be removed. After that, the test scenario
> described above should pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
