Understanding Hazelcast FencedLock: How it Works?

Overview

In distributed systems, synchronization and locking mechanisms are crucial to ensure data consistency and proper coordination between different nodes. Hazelcast, a well-known in-memory computing platform, offers several solutions for distributed locking, including Hazelcast FencedLock, which is a robust lock designed to ensure higher reliability in partitioned or multi-node environments.

This article explores the ins and outs of Hazelcast FencedLock, explaining its features, benefits, and use cases.

What is Hazelcast FencedLock?

Hazelcast FencedLock is a distributed, reentrant lock provided by Hazelcast, designed to work efficiently in clustered environments. Unlike traditional locking mechanisms that may fail during network partitioning or node failures, Hazelcast FencedLock ensures that only one client has exclusive access to a particular resource, and if failures occur, the lock remains functional without compromising data integrity.

The key feature that makes Hazelcast FencedLock stand out is its ability to handle split-brain situations, where network partitions can lead to multiple nodes thinking they hold the lock simultaneously. By using a fencing token, Hazelcast FencedLock prevents this, ensuring that only one client can perform operations on the locked resource.

Key Features of Hazelcast FencedLock

1. Fencing Tokens: Each time a client successfully acquires the lock, a unique fencing token is issued. This token can be used to ensure that stale operations are avoided. The fencing token increases monotonically, and only the client with the highest token is allowed to execute critical operations.
2. Strong Consistency Guarantees: FencedLock ensures that no two clients can hold the same lock at the same time, providing strong consistency across distributed systems.
3. Reentrant: It allows the same thread to lock the resource multiple times without causing a deadlock, which can be useful in recursive algorithms or nested locking scenarios.
4. Fault Tolerance: In the event of node failures or network partitioning, FencedLock guarantees that the lock remains available, providing higher availability and reliability.
5. Non-blocking: The lock acquisition can be done in a non-blocking way, meaning that if the lock is not available, the client can choose to continue with other tasks without waiting indefinitely.

Why Use Hazelcast FencedLock?

When working in a distributed environment, ensuring data integrity is challenging due to the complexity of node failures, network issues, and data synchronization. Traditional locking mechanisms like Java’s ReentrantLock or synchronized blocks may not work well in these scenarios, especially when the system is partitioned or nodes crash. This is where FencedLock becomes essential.

Here are some reasons why FencedLock is superior in distributed systems:

• Prevents Split-Brain Scenarios: During network partitions, FencedLock ensures that only one partition can operate on the locked resource using fencing tokens. This prevents multiple partitions from concurrently accessing and modifying the same data, a common issue in split-brain situations.
• High Availability: Even in cases where nodes go down or experience delays, FencedLock ensures that the lock remains consistent and can be re-acquired by other nodes, minimizing downtime.
• Ensures Data Consistency: When multiple clients attempt to modify shared resources in a distributed setup, FencedLock ensures that only one client can access the resource at any given time, preventing race conditions and ensuring consistent state updates.

How Hazelcast FencedLock Works

The core mechanism behind FencedLock is the issuance of fencing tokens. When a client acquires a lock, a fencing token is generated. This token is essential for the following reasons:

1. Monotonically Increasing Tokens: Each lock acquisition generates a fencing token, which is always higher than the previous token. This ensures that any operations issued by clients with lower tokens are rejected, thereby avoiding race conditions and stale data modifications.
2. Token Verification: The system that operates on the locked resource (e.g., a database or shared storage) can verify the fencing token to ensure that the operation is valid. If a client attempts to perform an operation with an old token, the system can deny it.
3. Automatic Failover: In the event of a client failure, other clients can acquire the lock, receive a new fencing token, and proceed with operations, ensuring that no stale operations from the failed client affect the system.

Example of FencedLock in Action

Here’s a simplified example of how FencedLock works in practice:

1. Client A and Client B both try to acquire a lock on the same resource.
2. Client A succeeds and is issued a fencing token of 100.
3. Client B fails to acquire the lock and retries after a short period.
4. Client A completes its task and releases the lock.
5. Client B acquires the lock next and receives a fencing token of 101.
6. If Client A tries to perform any further operations using the old token (100), the system will reject them because Client B now holds the latest valid token (101).

This mechanism ensures that only the most recent holder of the lock can proceed with operations, providing strong guarantees in a distributed environment.

Use Cases of Hazelcast FencedLock

Hazelcast FencedLock can be applied in various scenarios, especially in distributed systems where strong consistency and fault tolerance are required. Some key use cases include:

1. Leader Election

In distributed systems, it is often necessary to elect a leader that coordinates tasks or manages shared resources. FencedLock can be used to ensure that only one node holds the leader position at any given time. The fencing tokens guarantee that even during network partitions, only one node remains the leader.

2. Resource Management

When multiple nodes in a system are competing for a shared resource, such as database connections or memory buffers, FencedLock can ensure that only one node has access to the resource at a time, avoiding conflicts and ensuring fairness.

3. Data Consistency in Partitioned Systems

In cases where network partitions occur, FencedLock ensures that operations are only performed by the node with the highest fencing token. This is crucial for maintaining data consistency when multiple nodes are involved in data modification.

4. Distributed Transactions

For systems that require distributed transactions, ensuring that only one transaction is committed at a time is critical. FencedLock can be used to lock shared resources and ensure that only one node commits changes to a database or shared storage at a time, preventing transaction conflicts.

5. Failover Management

When a primary node fails, FencedLock can be used to assign the lock to a backup node, ensuring that operations continue without disruption. The fencing tokens help ensure that stale operations from the failed node do not interfere with the backup’s work.

How to Implement Hazelcast FencedLock

Implementing FencedLock in Hazelcast is straightforward, and it can be done using Hazelcast’s distributed data structures. Here’s a basic example of how to use FencedLock in a Java application:

package com.javatecharc.demo.lock;

import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;
import com.hazelcast.cp.lock.FencedLock;

public class FencedLockExample {
    public static void main(String[] args) {
        // Start a Hazelcast instance
        HazelcastInstance hazelcastInstance = Hazelcast.newHazelcastInstance();

        // Get a FencedLock from the CP Subsystem
        FencedLock fencedLock = hazelcastInstance.getCPSubsystem().getLock("java-tech-arc-lock-demo");

        // Acquire the lock and get the fencing token
        long token = fencedLock.lockAndGetFence();
        System.out.println(fencedLock.getServiceName());
        try {
            System.out.println("Lock acquired with token: " + token);

            // Critical section of the code
            performCriticalOperation(token);

        } finally {
            // Release the lock
            fencedLock.unlock();
            System.out.println("Lock released.");
        }

        // Shutdown the Hazelcast instance
        hazelcastInstance.shutdown();
    }

    private static void performCriticalOperation(long token) {
        // Example of a critical operation that uses the fencing token for validation
        System.out.println("Performing a critical operation with token: " + token);
        // Your business logic goes here
    }
}

Explanation:

1. HazelcastInstance: We start a Hazelcast instance using Hazelcast.newHazelcastInstance(). This creates a member that is part of the Hazelcast cluster.
2. FencedLock: The lock is retrieved using the getLock("myFencedLock") method from Hazelcast’s CP Subsystem. This ensures that the lock is part of a strongly consistent group of nodes.
3. lockAndGetFence(): This method locks the resource and returns a unique fencing token. The token is crucial because it helps prevent stale operations from clients that previously held the lock.
4. Critical Operation: Inside the try block, we perform a critical operation. This part simulates work that should only be done by the client that holds the lock.
5. Unlock: After the critical section is completed, the lock is released using unlock().
6. Shutdown: Finally, the Hazelcast instance is shut down cleanly.

This example shows how to use FencedLock to ensure that only one thread in a distributed system can perform a critical operation at a time. The fencing token provides additional security to prevent stale operations from affecting the system.

Best Practices for Using Hazelcast FencedLock

To get the most out of FencedLock, consider the following best practices:

• Use fencing tokens for validation: Ensure that the fencing tokens are always validated before performing operations on shared resources. This will help you avoid stale data and race conditions.
• Minimize lock contention: Try to minimize the amount of time that locks are held, as this will reduce contention and improve system throughput. Use fine-grained locking where possible.
• Handle failures gracefully: Ensure that your system can handle failures, including network partitions and node crashes, and re-acquire locks as necessary to continue operations.

Conclusion

Hazelcast FencedLock is a powerful tool for ensuring consistency and fault tolerance in distributed systems. By using fencing tokens, it provides a strong guarantee that only one client can hold a lock at a time, even in the face of network partitions or node failures. Whether you’re implementing leader election, managing shared resources, or ensuring data consistency in partitioned environments, FencedLock offers a reliable and efficient solution. Embracing this mechanism can help you build more resilient and robust distributed applications.

With its strong consistency guarantees and fault-tolerant architecture, FencedLock is an essential component in the toolkit of any developer working with distributed systems and in-memory computing platforms like Hazelcast.

The Hazelcast FencedLock code demo available on github.

Start Hazelcast Members and Client