Distributed Locks Are Dead; Long Live Distributed Locks

We create a new CP session when a Hazelcast server or client makes its very first lock or semaphore acquire request. Let’s see the CP session auto-cleanup mechanism in action:

In this code sample, a Hazelcast member acquires the lock and then crashes. Finally, a Hazelcast instance (both server and client) automatically closes its CP session on graceful shutdown:

To be precise, the CP Subsystem resets the CP session timeout in 3 circumstances:

As veteran distributed systems folks might have already noticed, we borrowed several ideas from Google’s paper “The Chubby lock service for loosely-coupled distributed system”.

Source: hazelcast.com