[ https://issues.apache.org/jira/browse/IGNITE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Menshikov updated IGNITE-4908: ---------------------------------------- Comment: was deleted (was: May be Later I will look at our lock implementations. Right now I wrote benchmark IgniteCache.lock(...) vs Ignite.reentrantLock(...). There are results: //Ignite.reentrantLock(...) Benchmark (create) (failoverSafe) (fair) Mode Cnt Score Error Units JmhCacheLocksBenchmark.testIgniteLocks true true true thrpt 10 873,775 ± 60,388 ops/s JmhCacheLocksBenchmark.testIgniteLocks true true false thrpt 10 1177,804 ± 162,082 ops/s JmhCacheLocksBenchmark.testIgniteLocks true false true thrpt 10 915,579 ± 42,631 ops/s JmhCacheLocksBenchmark.testIgniteLocks true false false thrpt 10 1176,044 ± 108,950 ops/s JmhCacheLocksBenchmark.testIgniteLocks false true true thrpt 10 926,890 ± 37,080 ops/s JmhCacheLocksBenchmark.testIgniteLocks false true false thrpt 10 1195,663 ± 73,578 ops/s JmhCacheLocksBenchmark.testIgniteLocks false false true thrpt 10 903,658 ± 78,483 ops/s JmhCacheLocksBenchmark.testIgniteLocks false false false thrpt 10 1159,586 ± 81,717 ops/s //IgniteCache.lock(...) Benchmark Mode Cnt Score Error Units JmhCacheLocksBenchmark.testCacheLocks thrpt 10 8076,522 ± 786,153 ops/s Looks like IgniteCache.lock(...) faster than Ignite.reentrantLock(...) at ~8 times. I will investigate the reason.) > Ignite.reentrantLock looks much slower than IgniteCache.lock. > ------------------------------------------------------------- > > Key: IGNITE-4908 > URL: https://issues.apache.org/jira/browse/IGNITE-4908 > Project: Ignite > Issue Type: Improvement > Components: data structures > Affects Versions: 1.8 > Reporter: Andrew Mashenkov > Assignee: Alexander Menshikov > Fix For: 2.3 > > > Design discussed with Alexander: > 1) Lock > Entry Processor (sync) -> > ....add candidate. > ....returns "added candidate at first position" > ....retry failover -> > ........if already at first position -> return true > In case lock not acquired, wait for acquire (AbstractQueuedSynchronizer > should be used). > 2) Unlock > Entry Processor (async) -> > ....remove candidate at first position > ....retry failover -> remove only if "candidate at first position" equals to > expected > ....listener -> > ........notify current "candidate at first position" it got lock > 3)Failover > 3.1) Originating node failed > Failed node listener -> > ....For each local(primary) lock -> > ........Entry Processor (async) -> > ............remove candidates related no failed node > ............retry failover not needed > ............listener -> > ................if "candidate at first position" removed -> > ....................notify current "candidate at first position" it got lock > 3.2) Primary node failed > After rebalancing schedule Callable -> > ....For each local(primary) lock -> > ........Entry Processor (async) -> > ............remove candidates related to failed nodes > ............retry failover not needed > ............listener -> > ................notify current "candidate at first position" it got lock -- This message was sent by Atlassian JIRA (v6.4.14#64029)