[
https://issues.apache.org/jira/browse/IGNITE-20895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-20895:
---------------------------------------
Description:
Recently a (not very efficient) parentLockManager [1] was introduced to handle
hierarchy (coarse-grained) locks.
Currently it's only purpose is to provide strict serializability during full
table scans, which happens very rarely.
It comes at the cost of acquiring additional lock on each update op. IS locks
are never used at all.
This should be improved. Possible optimizations:
# Get rid of hierarchy locks and instead scan the primary index for table
scan. If I recall correctly, Mysql never uses hierarchy locking.
# If we are absolutely sure that we need hierarchy locking, replace lock
queuing for IS,IX locks with counters. This prevents waiting, but is looks ok
for this kind of locks. Only stronger locks should be allowed to wait.
[1] org.apache.ignite.internal.tx.impl.HeapLockManager#parentLockManager
was:
Recently a (not very efficient) parentLockManager [1]was introduced to handle
hierarchy (coarse-grained) locks.
Currently it's only purpose is to provide strict serializability during full
table scans, which happed very rarely.
It comes at the cost of acquiring additional lock on each update op. IS locks
are never used at all.
It should be improved. Possible optimizations:
# Get rid of hierarchy locks and instead scan the primary index for table
scane.
# Replace lock queuing for IS,IX locks with counters. This prevents waiting,
but is looks ok for this kind of locks. Only stronger locks should be allowed
to wait.
[1] org.apache.ignite.internal.tx.impl.HeapLockManager#parentLockManager
> Optimize hierarchy lock manager
> -------------------------------
>
> Key: IGNITE-20895
> URL: https://issues.apache.org/jira/browse/IGNITE-20895
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Alexey Scherbakov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Recently a (not very efficient) parentLockManager [1] was introduced to
> handle hierarchy (coarse-grained) locks.
> Currently it's only purpose is to provide strict serializability during full
> table scans, which happens very rarely.
> It comes at the cost of acquiring additional lock on each update op. IS locks
> are never used at all.
> This should be improved. Possible optimizations:
> # Get rid of hierarchy locks and instead scan the primary index for table
> scan. If I recall correctly, Mysql never uses hierarchy locking.
> # If we are absolutely sure that we need hierarchy locking, replace lock
> queuing for IS,IX locks with counters. This prevents waiting, but is looks ok
> for this kind of locks. Only stronger locks should be allowed to wait.
> [1] org.apache.ignite.internal.tx.impl.HeapLockManager#parentLockManager
--
This message was sent by Atlassian Jira
(v8.20.10#820010)