hazelcasthazelcast-imap

Does IMap.lock() require CP subsystem?


The documentation says that the CP Subsystem is used for implementing distributed coordination use cases, such as leader election (Raft consensus algorithm), distributed locking, synchronization, and metadata management. By default, it operates in the "unsafe mode" and it even prints a warning to the console saying that strong consistency cannot be guaranteed.

On the other hand, it also says that when it comes to dealing with distributed data structures like IMap, the data will always be written and read from the primary replica by default.

So, if I have the CP Subsystem disabled and I use hazelcastInstance.getMap("accounts").lock("123"), would it be safe to assume no other cluster member will be able to do the same unless this one is released? Or do I have to actually configure the CP part just for this? I also use only a single replica without any backups if that makes any difference.

I think that it should be fine since all members will have to go to the same place for the lock. And also, it seems to me that the "distributed locking" part in the CP Subsystem actually means its own FencedLock that is accessible via hazelcastInstance.getCPSubsystem().getLock("myLock") and so the lock on the map is different.


Solution

  • Here is an answer that explains your question Hazelcast 3.12 IMap.lock() on Map better than ILock.lock() which is deprecated?

    IMap.lock(key) creates a lock object for that key on the same partition while other keys are still available. So it does not use CP Subsystem