[
https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18294:
----------------------------------
Description:
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.
> Multiple lock intentions support
> --------------------------------
>
> Key: IGNITE-18294
> URL: https://issues.apache.org/jira/browse/IGNITE-18294
> Project: Ignite
> Issue Type: Bug
> Reporter: Denis Chudov
> Priority: Major
> Labels: ignite-3
>
> 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)
