[
https://issues.apache.org/jira/browse/IGNITE-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18351:
----------------------------------
Description:
*Motivation*
Recently, we redesigned the behavior of lock manager, but did not modify the
interface. This leads to the inconsistency between method name and what the
method actually does.
The ticket inspires to improve interface of lock manager to avoid wrong usage
of the interface.
* The lock mode LockMode#NL is used nowhere. It is s candidate for removal.
* The LockManager#release(org.apache.ignite.internal.tx.Lock) accepts lock
object as a parameter, but actually removes all locks of a particular
transaction. It should be redesigned in order to accept transaction id as a
parameter..
* The LockManager#release(UUID, LockKey, LockMode) releases a particular lock
mode on a particular key. It should accept lock object as a parameter.
*Definition of done*
Only two following methods related to release should remain in LockManager
interface:
- release(transactionId) // releases all locks that belong to specified
transaction
- release(lock) // releases specific lock
*Implementation notes:*
Only minor changes will be required in production code outside of lock manager,
as only mentioned methods are really needed.
Current implementation of LockManager#acquire returns a future containing
supremum lock mode as a result, but we will need the lock that was intended to
be acquired, to release it later.
was:
*Motivation*
Recently, we redesigned the behavior of lock manager, but did not modify the
interface. This leads to the inconsistency between method name and what the
method actually does.
The ticket inspires to improve interface of lock manager to avoid wrong usage
of the interface.
* The lock mode LockMode#NL is used nowhere. It is s candidate for removal.
* The LockManager#release(org.apache.ignite.internal.tx.Lock) accepts lock
object as a parameter, but actually removes all locks of a particular
transaction. It should be redesigned in order to accept transaction id as a
parameter..
* The LockManager#release(UUID, LockKey, LockMode) releases a particular lock
mode on a particular key. It should accept lock object as a parameter.
*Definition of done*
Only two following methods related to release should remain in LockManager
interface:
- release(transactionId) // releases all locks that belong to specified
transaction
- release(lock) // releases specific lock
*Implementation notes:*
Only minor changes will be required in production code outside of lock manager,
as only mentioned methods are really needed.
> Make a lock management interface more friendly
> ----------------------------------------------
>
> Key: IGNITE-18351
> URL: https://issues.apache.org/jira/browse/IGNITE-18351
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Recently, we redesigned the behavior of lock manager, but did not modify the
> interface. This leads to the inconsistency between method name and what the
> method actually does.
> The ticket inspires to improve interface of lock manager to avoid wrong usage
> of the interface.
> * The lock mode LockMode#NL is used nowhere. It is s candidate for removal.
> * The LockManager#release(org.apache.ignite.internal.tx.Lock) accepts lock
> object as a parameter, but actually removes all locks of a particular
> transaction. It should be redesigned in order to accept transaction id as a
> parameter..
> * The LockManager#release(UUID, LockKey, LockMode) releases a particular lock
> mode on a particular key. It should accept lock object as a parameter.
> *Definition of done*
> Only two following methods related to release should remain in LockManager
> interface:
> - release(transactionId) // releases all locks that belong to specified
> transaction
> - release(lock) // releases specific lock
> *Implementation notes:*
> Only minor changes will be required in production code outside of lock
> manager, as only mentioned methods are really needed.
> Current implementation of LockManager#acquire returns a future containing
> supremum lock mode as a result, but we will need the lock that was intended
> to be acquired, to release it later.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)