Zookeeper Locks – Shared & Recoverable Shared Locks

Boost your career with Free Big Data Courses!!

In our last ZooKeeper tutorial, we discussed the ZooKeeper Data Model. Today, we will see Zookeeper Locks. Moreover, we will discuss shared locks and recoverable shared locks in ZooKeeper. Also, we will see how to implement shared locks in ZooKeeper. 

So, let’s start ZooKeeper Locks.

What is Zookeeper Locks?

Zookeeper Locks are fully distributed locks in ZooKeeper which are globally synchronous. However, globally synchronous means at any snapshot in time no two clients think they hold the same lock.

Though these we can implement these locks by using ZooKeeper. Moreover, we can say first define a lock node, as with priority ZooKeeper Queues.

Now do the following, to obtain a lock in ZooKeeper:

  • With the sequence, ephemeral flags set and a pathname of “_locknode_/lock-“, Call create( ).
  • Further, without setting the watch flag, Call getChildren( ) on the lock node.
  • Moreover, the client has the lock and the client exits the protocol if the pathname created in step 1 has the lowest sequence number suffix.
  • Also, with the watch flag set on the path in the lock directory, the client calls exists( ) with the next lowest sequence number.
  • Else, go to step 2, if exists( ) returns false. Or rather, before going to step 2 wait for a notification for the pathname from the previous step.

However, clients wishing to release a lock in ZooKeeper simply delete the node they created in step 1, to unlock.

Also, notice these few things in ZooKeeper Locks:

  • Since each node is watched by exactly one client, the removal of a node will only cause one client to wake up. In this way, you avoid the herd effect.
  • Moreover, there is no polling or timeouts.
  • Also, it is easy to see the amount of lock contention, debug locking problems, break locks, etc, because of the way we implement locking.

Shared Locks

By making some changes to the ZooKeeper Lock protocol, it is possible to implement shared locks in ZooKeeper:

ZooKeeper Locks

ZooKeeper Locks –

a. Obtaining a Read lock

  1. At first, to create a node with pathname “_locknode_/read-“, Call create( ). Although, don’t forget to set both the sequence and ephemeral flags.
  2. Then without setting the watch flag, call getChildren( ) on the lock node. Basically, that helps to avoid the herd effect.
  3. However, make sure the client has the lock and can exit the protocol if somehow there are no children with a pathname starting with “write-” and having a lower sequence number than the node created in step 1.
  4. Else, call exists( ), with “write-” having the next lowest sequence number set on the node in lock directory with pathname starting, also with watch flag.
  5. Go to step 2, if exists( ) returns false.
  6. Else, before going to step 2, wait for a notification for the pathname from the previous step.

b. Obtaining a Write Lock

  1. Again, with pathname “_locknode_/write-“, call create( ) to create a node. And, remember to set both sequence and ephemeral flags.
  2. Further, call getChildren( ) on the lock node – because it helps to avoid the herd effect.
  3. However, the client has the lock and the client exits the protocol if there are no children with a lower sequence number than the node created in step 1.
  4. Further, with watch flag set, call exists( ), on the node with the pathname which has the next lowest sequence number.
  5. Goto step 2, if exists( ) returns false. Else, before going to step 2, wait for a notification for the pathname from the previous step.

Recoverable Shared Locks

Further, we can make ZooKeeper Shared Locks revocable by modifying the shared lock protocol, with minor modifications to the Shared Lock Protocol in ZooKeeper:

Just call getData( ) with watch set, in step 1, of both obtain reader and writer lock protocols, just after the call to create( ).

So, it created in step 1, if the client subsequently receives notification for the node, moreover, with watch set and looks for the string “unlock”, it does another getData( ) on that node, that signifies the client that now it must release the lock.

The reason behind this is, as per this shared lock protocol, writing “unlock” to that node, we can request the client with the lock give up the lock by calling setData() on the lock node.

So, this was all in ZooKeeper Locks. Hope you like our explanation.

Conclusion

Hence, we have seen the whole about Zookeeper Locks along with Shared Locks and Recoverable Shared Locks in detail. So, we hope this article will resolve all your doubts regarding Locks in ZooKeeper. Still, if any query, ask in the comment tab.

Did you like our efforts? If Yes, please give DataFlair 5 Stars on Google

follow dataflair on YouTube

Leave a Reply

Your email address will not be published. Required fields are marked *