[
https://issues.apache.org/jira/browse/IGNITE-15932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin resolved IGNITE-15932.
--------------------------------------
Resolution: Won't Fix
It's not necessary to implement persistent storage for locks, because we still
don't know whether it's required to replicate intention locks
(https://issues.apache.org/jira/browse/IGNITE-17422), so that we might use
writeIntents in order to recreate X locks on primary replica switch. Besides
that we are currently fine with scanning over whole partition in order to
convert writeIntents to X locks.
So, within the context of lock storage, it's only required to add a sort of
lock index by txId in order to evaluate Iterable<Lock> locks(UUIDtxId)
efficiently. And it definitely worth to do it in-place, meaning within
https://issues.apache.org/jira/browse/IGNITE-16892.
> Implement storage for locks
> ---------------------------
>
> Key: IGNITE-15932
> URL: https://issues.apache.org/jira/browse/IGNITE-15932
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexey Scherbakov
> Assignee: Alexander Lapin
> Priority: Major
> Labels: ignite-3, transaction3_rw
>
> Currently locks are stored in the heap and can take unlimited amount of
> memory.
> Need to implement storage for a locks with a configurable limits. It can even
> store locks off-heap of use disk spilling.
> Lock attempt must fail if a storage is overflowed.
> *Upd:*
> It's required to introduce both volatile and persistent storages for locks.
> Volatile storages will be used directly from replica, persistent ones will
> be populated from within corresponding ParitionListeners.
> Volatile storage will manager both read and write locks for all types of lock
> entities: rowIds, index keys, tables, indexes, meaning that it covers both
> common and intent locks.
> It's an open question whether persistent storage should handle (and replicate
> intent locks), so for now it will only handle common write locks. Please pay
> attention that persistent storage should be fully integrated into raft
> replication logic: snapshots, checkpointIndexes, etc.
> To sum up, persistent storage isn't a part of transactions3_rw stable
> support, however it's better to implement it from the very begging.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
