[jira] [Updated] (IGNITE-18294) Multiple lock intentions support

["Denis Chudov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Denis Chudov updated IGNITE-18294:
----------------------------------
    Fix Version/s: 3.0.0-beta2

> 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
>             Fix For: 3.0.0-beta2
>
>          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)