[
https://issues.apache.org/jira/browse/IGNITE-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787960#comment-17787960
]
Alexey Scherbakov edited comment on IGNITE-17811 at 11/20/23 12:03 PM:
-----------------------------------------------------------------------
This PR includes some optimizations and fixes. Most important:
# HeapLockManager now has additional index on all enlisted locks into a
transaction.
# A new method org.apache.ignite.internal.tx.impl.HeapLockManager#releaseAll
was introduced to release transaction locks in most efficient way.
# A lock table now has a size limitation to avoid hash map to grow without
bounds. If a size limit is extended, keys are mapped directly to raw slots
using hash function of a key. Still the lock queue has no limit size, it has to
be addressed as well.
# A more efficient hash function murmur3 is used for byte array keys. Is has
better collision resistance than a default hash function.
# LockManagerBenchmark was introduced to measure single threaded locking speed.
# A hierarchy (coarse grained) locking was refactored to additional lock table
for a further improvement, see
https://issues.apache.org/jira/browse/IGNITE-20895
# Some memory leaks in tests related to mockito were fixed. It is recommended
to have clearInlineMocks for each method instead of a suite, because the suite
can be quite big and produce OOMs with a current lock table size.
# A ticket was filed for incorrect behavior of commit in a deadlock scenario
https://issues.apache.org/jira/browse/IGNITE-20894
One of possible fixes is to implement pre-commit waiting (based on counters)
for reads as well (removing server side wait queues, which are bad for heap
usage)
was (Author: ascherbakov):
This PR includes some optimizations and fixes. Most important:
# HeapLockManager now has additional index on all enlisted locks into a
transaction.
# A new method org.apache.ignite.internal.tx.impl.HeapLockManager#releaseAll
was introduced to release transaction locks in most efficient way.
# A lock table now has a size limitation to avoid hash map to grow without
bounds. If a size limit is extended, keys are mapped directly to raw slots
using hash function of a key. Still the lock queue has no limit size, it has to
be addressed as well.
# A more efficient hash function murmur3 is used for byte array keys. Is has
better collision resistance than a default hash function.
# LockManagerBenchmark was introduced to measure single threaded locking speed.
# A hierarchy (coarse grained) locking was refactored to additional lock table
for a further improvement, see
https://issues.apache.org/jira/browse/IGNITE-20895
# Some memory leaks in tests related to mockito were fixed. It is recommended
to have clearInlineMocks for each method instead of a suite, because the suite
can be quite big and produce OOMs with a current lock table size.
# A ticket was filed for incorrect behavior of commit in a deadlock scenario
https://issues.apache.org/jira/browse/IGNITE-20894
> Implement efficient way to retrieve locks by txId
> -------------------------------------------------
>
> Key: IGNITE-17811
> URL: https://issues.apache.org/jira/browse/IGNITE-17811
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> org.apache.ignite.internal.tx.impl.HeapLockManager#locks require better
> implementation that'll use index or similar instead of full locks set
> iteration.
> {code:java}
> public Iterator<Lock> locks(UUID txId) {
> // TODO: tmp, use index instead.
> List<Lock> result = new ArrayList<>();
> for (Map.Entry<LockKey, LockState> entry : locks.entrySet()) {
> Waiter waiter = entry.getValue().waiter(txId);
> if (waiter != null) {
> result.add(
> new Lock(
> entry.getKey(),
> waiter.lockMode(),
> txId
> )
> );
> }
> }
> return result.iterator();
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
