The document discusses using Hazelcast distributed locks to synchronize access to critical sections of code across multiple JVMs and application instances. It describes how Hazelcast implements distributed versions of common Java data structures, including distributed locks via its ILock interface. It provides examples of configuring a Hazelcast cluster programmatically by specifying cluster properties like IP addresses and ports, and shows how to obtain and use a distributed lock within a try-finally block to ensure it is released.

1. Hazelcast Distributed Lock
Jadson Santos

2. Problem
• Some times you need a critical region in your system
where 2 threads can not access this part of code
concurrently, or something wrong will happen
•
• The easiest way to do this, is used the Java synchronized
block:
20/03/17 Hazelcast distributed lock

3. Problem
• The problem with this approach is that it just work in the
same Java Virtual Machine.
•
• What can we do if we have several instances of our
application running?
•
20/03/17 Hazelcast distributed lock

4. DataBase Distributed Lock
• The first option is use database based lock
•
• With Hibernate we have something like this:
•
20/03/17 Hazelcast distributed lock

5. DataBase Distributed Lock
• If two threads call the findObjectLock method at same
time, the second one you will wait until the first transaction
is closed.
•
• But if we have several databases or we can not use the
lock of the database?
•
20/03/17 Hazelcast distributed lock

6. HazelCast Distributed Lock
• The Hazelcast IMDG operational in-memory computing
platform helps leading companies worldwide manage their
data and distribute processing using in-memory storage
and parallel execution for breakthrough application speed
and scale [1].
•
• Hazelcast implement a distributed version of some Java
data structures like Maps, Set, Lists, Queue and Lock
•
20/03/17 Hazelcast distributed lock

7. HazelCast Distributed Lock
• ILock is the distributed implementation of
java.util.concurrent.locks.Lock. Meaning if you lock using
an ILock, the critical section that it guards is guaranteed
to be executed by only one thread in the entire cluster [2].
•
20/03/17 Hazelcast distributed lock

8. Configuring HazelCast
• Just add a simple Jar to the application classpath.
•
• With Gradle stay like this:
•
20/03/17 Hazelcast distributed lock

9. Configuring HazelCast Cluster
• Programmatically you need initiated a Config object for
the HazelCast instance
•
•
•
•
•
• First of all, we choose the cluster initial port number and
the number of ports the cluster we use.
•
• If you have several threads at same time access the
cluster, it is necessary have several ports
•
20/03/17 Hazelcast distributed lock

10. Configuring HazelCast Cluster
• After that, we need to chose if use Multicast or specific
IPs addresses in the cluster, we configure to use specific
IPs
•
•
•
•
•
•
•
20/03/17 Hazelcast distributed lock

11. Configuring HazelCast Cluster
• Now we inform these specific IPs to the cluster
•
•
•
•
•
•
•
20/03/17 Hazelcast distributed lock

12. Configuring HazelCast Cluster
• At last, we specify which network interfaces that
Hazelcast should use
•
•
•
•
•
•
•
20/03/17 Hazelcast distributed lock

13. Configuring HazelCast Cluster
• We can now instantiate a new Hazelcast Instance with
this configuration, how iniciate a Hazelcast instance is
slow, takes around 3 seconds, we initialized just one
instance per JVM
20/03/17 Hazelcast distributed lock

14. Configuring HazelCast Cluster
• The complete code:
20/03/17 Hazelcast distributed lock

15. Using HazelCast Cluster
• You must call HazelCast lock in a try-finally block to
ensure that the lock will be release.
• The lock have an identifier, so we can have different locks
in the same cluster
20/03/17 Hazelcast distributed lock

16. References
• [1] Hazelcast IMDG. The Leading Open Source In-
Memory Data Grid. https://hazelcast.org/
•
• [2] Lock
http://docs.hazelcast.org/docs/3.5/manual/html/lock.html
20/03/17 Hazelcast distributed lock