Apache Curator: distributed (try) locks

Apache Curator provides different types of distributed locks such as a basic one, re-entrant lock, re-entrant read write lock etc. In this blog we look at one such lock implementation (an InterProcessMutex )

  • its API
  • how it simulates the tryLock feature in Java Lock
  • walk through sample code

Code available on Github


Apache Curator: the keeper for Zookeeper

InterProcessMutex API

It has a simple API where the primary components are

  • the constructor itself: how to instantiate a distributed lock
  • acquire the lock
  • relinquish (release) the lock

Prior to entering a critical section, an application or process would need to obtain a lock in order to ensure that it is the only one executing that piece of logic

Block for Lock

What’s important to understand is that the acquire method blocks until the lock is available. This has some important implications for multiple processes which are competing for this lock

  • Only one will succeed – this is obvious
  • Since acquire method blocks, the other processes will queue up
  • The queuing up will happen in a fair manner (as per implementation) i.e. the process which calledacquire first (as per Zookeeper, not as per the application) will be the next in queue to get the lock once it’s released by the process which actually has the lock

Depending upon your use case, you might or might not want the queuing effect. For example

  • A node in your application gets the lock, finish a part of the job (and save it state to a shared location like a DB) and release the lock. You might want that the other node in that the application to continue processing from where the previous node left – using acquire to let the nodes wait in a queue makes sense
  • If you have a scheduled timer distributed across multiple nodes in your cluster and need it to be executed by one node at a time, then you might want to use the overloaded form of acquire method. This will avoid queing up effect of processes – its something wich you would not want since the timer is already pre-configured to fire after certain intervals

Distributed try lock

Just like the tryLock method in Java’s Lock, the InterProcessMutex provides an overloaded version of acquire which accepts a time out. It does not block – all it does is the following

  • returns true if the lock is obtained within the stipulated time out
  • returns false i.e. it gives up if the lock is not available and the time out is breached

Code walk through

Details in the Github project README

Further reading



About Abhishek

Loves Java EE, distributed KV stores and messaging systems. Frequently blogs at abhirockzz.wordpress.com as well as simplydistributed.wordpress.com. Oh, I have also authored a few (mini) books, articles, Refcards etc. :-)
This entry was posted in Curator, Distributed systems, Zookeeper and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s