Hazelcast Distributed Map (IMap) is thread-safe to meet your thread safety requirements. When these requirements increase or you want to have more control on the concurrency, consider the Hazelcast solutions described here.

Let’s work on a sample case as shown below.

public class RacyUpdateMember { public static void main( String[] args ) throws Exception { HazelcastInstance hz = Hazelcast.newHazelcastInstance(); IMap<String, Value> map = hz.getMap( "map" ); String key = "1"; map.put( key, new Value() ); System.out.println( "Starting" ); for ( int k = 0; k < 1000; k++ ) { if ( k % 100 == 0 ) System.out.println( "At: " + k ); Value value = map.get( key ); Thread.sleep( 10 ); value.amount++; map.put( key, value ); } System.out.println( "Finished! Result = " + map.get(key).amount ); } static class Value implements Serializable { public int amount; }}Copy the code

If the above code is run by more than one cluster member simultaneously, a race condition is likely. You can solve this condition with Hazelcast using either pessimistic locking or optimistic locking.

Pessimistic Locking

One way to solve the race issue is by using pessimistic locking–lock the map entry until you are finished with it.

To perform pessimistic locking, use the lock mechanism provided by the Hazelcast distributed map, i.e., the map.lock and map.unlock methods. See the below example code.

public class PessimisticUpdateMember { public static void main( String[] args ) throws Exception { HazelcastInstance hz = Hazelcast.newHazelcastInstance(); IMap<String, Value> map = hz.getMap( "map" ); String key = "1"; map.put( key, new Value() ); System.out.println( "Starting" ); for ( int k = 0; k < 1000; k++ ) { map.lock( key ); try { Value value = map.get( key ); Thread.sleep( 10 ); value.amount++; map.put( key, value ); } finally { map.unlock( key ); } } System.out.println( "Finished! Result = " + map.get( key ).amount ); } static class Value implements Serializable { public int amount; }}Copy the code

The IMap lock will automatically be collected by the garbage collector when the lock is released and no other waiting conditions exist on the lock.

The IMap lock is reentrant, but it does not support fairness.

Another way to solve the race issue is by acquiring a predictable Lock object from Hazelcast. This way, every value in the map can be given a lock, or you can create a stripe of locks.

Optimistic Locking

In Hazelcast, you can apply the optimistic locking strategy with the map’s replace method. This method compares values in object or data forms depending on the in-memory format configuration. If the values are equal, it replaces the old value with the new one. If you want to use your defined equals method, in-memory-format should be OBJECT. Otherwise, Hazelcast serializes objects to BINARY forms and compares them.

See the below example code.

NOTE: The below example code is intentionally broken.

public class OptimisticMember { public static void main( String[] args ) throws Exception { HazelcastInstance hz = Hazelcast.newHazelcastInstance(); IMap<String, Value> map = hz.getMap( "map" ); String key = "1"; map.put( key, new Value() ); System.out.println( "Starting" ); for ( int k = 0; k < 1000; k++ ) { if ( k % 10 == 0 ) System.out.println( "At: " + k ); for (; ;) { Value oldValue = map.get( key ); Value newValue = new Value( oldValue ); Thread.sleep( 10 ); newValue.amount++; if ( map.replace( key, oldValue, newValue ) ) break; } } System.out.println( "Finished! Result = " + map.get( key ).amount ); } static class Value implements Serializable { public int amount; public Value() { } public Value( Value that ) { this.amount = that.amount; } public boolean equals( Object o ) { if ( o == this ) return true; if ( ! ( o instanceof Value ) ) return false; Value that = ( Value ) o; return that.amount == this.amount; }}}Copy the code

Pessimistic vs. Optimistic Locking

The locking strategy you choose will depend on your locking requirements.

Optimistic locking is better for mostly read-only systems. It has a performance boost over pessimistic locking.

Pessimistic locking is good if there are lots of updates on the same key. It is more robust than optimistic locking from the perspective of data consistency.

In Hazelcast, use IExecutorService to submit a task to a key owner, or to a member or members. This is the recommended way to perform task executions, rather than using pessimistic or optimistic locking techniques. IExecutorService will have fewer network hops and less data over wire, and tasks will be executed very near to the data. Please refer to the Data Affinity section.

Solving the ABA Problem

The ABA problem occurs in environments when a shared resource is open to change by multiple threads. Even if one thread sees the same value for a particular key in consecutive reads, it does not mean that nothing has changed between the reads. Another thread may change the value, do work, and change the value back, while the first thread thinks that nothing has changed.

To prevent these kind of problems, you can assign a version number and check it before any write to be sure that nothing has changed between consecutive reads. Although all the other fields will be equal, the version field will prevent objects from being seen as equal. This is the optimistic locking strategy, and it is used in environments that do not expect intensive concurrent changes on a specific key.

In Hazelcast, you can apply the optimistic locking strategy with the map replace method.

Lock Split-Brain Protection with Pessimistic Locking

Locks can be configured to check the number of currently present members before applying a locking operation. If the check fails, the lock operation will fail with a QuorumException (see Split-Brain Protection). As pessimistic locking uses lock operations internally, it will also use the configured lock quorum. This means that you can configure a lock quorum with the same name or a pattern that matches the map name. Note that the quorum for IMap locking actions can be different from the quorum for other IMap actions.

The following actions will then check for lock quorum before being applied:

  • IMap#lock(K) and IMap#lock(K, long, java.util.concurrent.TimeUnit)
  • IMap#isLocked
  • IMap#tryLock(K).IMap#tryLock(K, long, java.util.concurrent.TimeUnit) and IMap#tryLock(K, long, java.util.concurrent.TimeUnit, long, java.util.concurrent.TimeUnit)
  • IMap#unlock
  • IMap#forceUnlock
  • MultiMap#lock(K) and MultiMap#lock(K, long, java.util.concurrent.TimeUnit)
  • MultiMap#isLocked
  • MultiMap#tryLock(K).MultiMap#tryLock(K, long, java.util.concurrent.TimeUnit) and MultiMap#tryLock(K, long, java.util.concurrent.TimeUnit, long, java.util.concurrent.TimeUnit)
  • MultiMap#unlock
  • MultiMap#forceUnlock

An example of declarative configuration:

<map name="myMap">
  <quorum-ref>map-actions-quorum</quorum-ref>
</map>

<lock name="myMap">
    <quorum-ref>map-lock-actions-quorum</quorum-ref>
</lock>
Copy the code

Here the configured map will use the map-lock-actions-quorum quorum for map lock actions and the map-actions-quorum quorum for other map actions.