[
https://issues.apache.org/jira/browse/IGNITE-18192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18192:
----------------------------------
Description:
*Motivation:*
According to transaction IEP [1], insert into non-unique sorted index happens
as follows:
// insert
- IX_short(nextKey)
- X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
- IX_commit(currentKey) otherwise
So in some cases we can acquire lock in weaker mode (IX instead of X ).
To be able to do this, we need an API extension for LockManager: a method which
atomically does following actions:
- checks a lock mode of a lock that is currently held on a key A
- selects a needed lock mode for key B
- acquires lock for key B with selected mode.
*Definition of done:*
Added a method to LockManager:
{{CompletableFuture<Lock> acquire(UUID txId, LockKey keyToLock, LockKey
keyToCheck, Function<LockMode, LockMode>);}}
The function passed as a parameter, should accept the current lock mode on key
keyToCheck and return a lock mode that is supposed to be acquired by the method
for key keyToLock.
*Implementation notes:*
This method will have to synchronize on multiple keys in LockManager. We should
take into account that {{LockKey}} is not comparable and specify in the method
description that the keys passed into the method must be ordered relying on
index order to prevent deadlocks.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
was:
*Motivation:*
According to transaction IEP, insert into non-unique sorted index happens as
follows:
// insert
- IX_short(nextKey)
- X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
- IX_commit(currentKey) otherwise
So in some cases we can acquire lock in weaker mode (IX instead of X ).
To be able to do this, we need an API extension for LockManager: a method which
atomically does following actions:
- checks a lock mode of a lock that is currently held on a key A
- selects a needed lock mode for key B
- acquires lock for key B with selected mode.
*Definition of done:*
Added a method to LockManager:
{{CompletableFuture<Lock> acquire(UUID txId, LockKey keyToLock, LockKey
keyToCheck, Function<LockMode, LockMode>);}}
The function passed as a parameter, should accept the current lock mode on key
keyToCheck and return a lock mode that is supposed to be acquired by the method
for key keyToLock.
*Implementation notes:*
This method will have to synchronize on multiple keys in LockManager. We should
take into account that {{LockKey}} is not comparable and specify in the method
description that the keys passed into the method must be ordered relying on
index order to prevent deadlocks.
> Conditional lock
> ----------------
>
> Key: IGNITE-18192
> URL: https://issues.apache.org/jira/browse/IGNITE-18192
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> *Motivation:*
> According to transaction IEP [1], insert into non-unique sorted index happens
> as follows:
> // insert
> - IX_short(nextKey)
> - X_commit(currentKey) if nextKey previously locked in S, X or SIX mode
> - IX_commit(currentKey) otherwise
> So in some cases we can acquire lock in weaker mode (IX instead of X ).
> To be able to do this, we need an API extension for LockManager: a method
> which atomically does following actions:
> - checks a lock mode of a lock that is currently held on a key A
> - selects a needed lock mode for key B
> - acquires lock for key B with selected mode.
> *Definition of done:*
> Added a method to LockManager:
> {{CompletableFuture<Lock> acquire(UUID txId, LockKey keyToLock, LockKey
> keyToCheck, Function<LockMode, LockMode>);}}
> The function passed as a parameter, should accept the current lock mode on
> key keyToCheck and return a lock mode that is supposed to be acquired by the
> method for key keyToLock.
> *Implementation notes:*
> This method will have to synchronize on multiple keys in LockManager. We
> should take into account that {{LockKey}} is not comparable and specify in
> the method description that the keys passed into the method must be ordered
> relying on index order to prevent deadlocks.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
