1

I am evaluating the best approach to distributed locking. The oob reentrant locking support in Ignite is tied to the thread that acquires locks. Our requirements need locking and unlocking not tied to the same thread/process, one thread/process can lock and other thread/process can unlock. So while evaluating alternatives, we came across 2 options,

  1. Use semaphores - This works but is extremely slow. Cannot use this.
  2. Do manual locking - Use a separate cache where we add entries for locks and remove entries for unlock. But it needs too many cases to handle like nodes going down during put ops, which other node gets through, etc.

Just wanted to check if there are other oob performant options available that we might have overlooked.

TIA

Victor
  • 1,207
  • 2
  • 13
  • 21
  • Could you please describe the actual use case? Why is a distributed lock needed? I wonder if we have an XY problem here (https://xyproblem.info/). – Pavel Tupitsyn Feb 20 '23 at 09:50
  • Serialized access to a shared entity in a multi threaded app where one thread is expected to lock the entity access and another thread release the lock. Our product exposes the locking feature for end user apps to use. HTH – Victor Feb 21 '23 at 07:29
  • Have you tried p2, but with transactions? Pessimistic serializable tx might help achieve the desired behavior. https://ignite.apache.org/docs/latest/key-value-api/transactions – Pavel Tupitsyn Feb 21 '23 at 10:47
  • How is the transaction object accessible across threads? One thread creating+starting the transaction and another thread commits it. – Victor Feb 21 '23 at 16:46
  • `suspend` and `resume` methods of `Transaction` interface provide a way to "migrate" a transaction to another thread. – Pavel Tupitsyn Feb 22 '23 at 20:30
  • The API atleast don't seem to tell me how to use suspend and resume split between 2 threads. How does the 2nd thread get access to the same transaction object, i thought 'label' would help, but i don't see any api's to fetch a transaction by label/id. Also the api says, suspend/resume work only with optimistic transactions. – Victor Feb 23 '23 at 05:17
  • "How does the 2nd thread get access to the same transaction object" - just use the same object, call suspend on one thread, resume on another. But yes, it is only for optimistic. Looks like there is no built-in way to achieve thread blocking in a way that you described. – Pavel Tupitsyn Feb 23 '23 at 06:04
  • Can you tell more about how slow are the semaphores? They or the IgniteLock should be the OOB solution in principle. – Stanislav Lukyanov Feb 25 '23 at 05:57
  • IgniteLock is not an option as I already mentioned since it's tied to a thread. Manual implementation of doing put for locking and remove for unlocking in a cache is more than twice as fast as using semaphores. – Victor Feb 28 '23 at 19:01

0 Answers0