added checks local lock state before DB insert in shared token selector

[Horiodino]

This PR fixes #886 by adding a local lock check before attempting DB lock insertion in the shared token selector.
The selector now tracks tokens already locked by the current replica and skips duplicate TryLock calls for the same token within the same selection cycle. The local lock state is cleared during UnlockAll().
This avoids unnecessary DB round trips and optimistic insert failures when duplicate tokens are returned by the iterator.

[adecaro]

Hi @Horiodino , thanks for submitting this. I'll review ASAP.

A first comment though. A cache per selector might not be helpful because other selectors might end up choosing tokens already selected. I would investigate a more global locker instantiated at the manager level and passed to each selector.

[adecaro]

Hi @Horiodino , did you have time to look at my comment?
Thanks 🙏

[Horiodino]

Hey , i have moved the implementation from a per-selector cache to a shared local lock tracker,different selectors are aware of tokens already locked within the same replica, could you review? , i would fix the conflicts asap if it looks good.

[adecaro]

why don't we pass an instance of locker that embeds the behavior of your localTokenLockTracker directly? This would reduce the code impact.

[Horiodino]

good point,i kept them separate because the Locker represents the shared/external locking mechanism, while the localTokenLockTracker is strictly in-memory .

keeeping that split avoids coupling the Locker to local state and makes the behavior explicit, since not all Locker implementations are necessarily local-aware.

[adecaro]

fair enough 👍

[adecaro]

Hi @Horiodino , I left an initial comment. But, I also need you to run the benchmarks in token/services/selector/benchmark_test.go to prove that this feature does not make it worse the performance of the selector which sits on the critical path of a transaction execution.
Please, make sure we can have a very efficient implementation of this local check.

Many thanks for your effort 🙏

[adecaro]

Hi @Horiodino , any news?

[Horiodino]

from the benchmark comparison I ran (current branch vs baseline):

sherdlock slowdown (time)
SelectorSingle/sherdlock: +56.24%
SelectorParallel/sherdlock: +881.99%
SelectorSingle/sherdlock+lock: +46.17%
SelectorParallel/sherdlock+lock: +22.32%
SelectorParallel/sherdlock+lock+parallelism: +47.79%
Memory impact (sherdlock paths)
B/op roughly +24% to +44% (depending on case)
allocs/op about +0.6% to +1.1%

it checks a local in-memory lock map,then also checks shared local lock state,this happens in a loop.
currently im trying to optimize it .

[adecaro]

Hi @Horiodino , any progress on this PR?
Thanks for the effort so far 🙏