[jira] [Comment Edited] (IGNITE-17811) Implement efficient way to retrieve locks by txId

["Alexey Scherbakov (Jira)" <ji...@apache.org>]

    [ 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 11:33 AM:
-----------------------------------------------------------------------

This PR includes some optimizations and fixes. Most important:
 # HeapLockManager 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 manage single threaded locking speed.
 # A hierarchy (coarse grained) locking was refactored to additinal 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 leaks.
 # A ticket was filed for incorrect behavior of commit in a deadlock scenario https://issues.apache.org/jira/browse/IGNITE-20894


was (Author: ascherbakov):
This PR includes some optimizations and fixes. Most important:
 # HeapLockManager 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 manage single threaded locking speed.
 # A hierarchy (coarse grained) locking was refactored to additinal 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 leaks.

> 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)