Hazelcast is the distributed implementation of several structures that exist in Java. Most of the time it behaves as you expect. However there are some design choices in Hazelcast that violate some contracts. This page will list those violations.
equals() and hashCode() methods for the objects stored in Hazelcast
When you store a key, value in a distributed Map, Hazelcast serializes the key and value and stores the byte array version of them in local ConcurrentHashMaps. And this ConcurrentHashMap uses the equals and hashCode methods of byte array version of your key. So it does not take into account the actual equals and hashCode implementations of your objects. So it is important that you choose your keys in a proper way. Implementing the equals and hashCode is not enough, it is also important that the object is always serialized into the same byte array. All primitive types, like; String, Long, Integer and etc. are good candidates for keys to use in Hazelcast. An unsorted Set is an example of a very bad candidate because Java Serialization may serialize the same unsorted set in two different byte arrays.
Note that the distributed Set and List stores its entries as the keys in a distributed Map. So the notes above apply to the objects you store in Set and List.
Hazelcast always return a clone copy of a value. Modifying the returned value does not change the actual value in the map (or multimap or list or set). You should put modified value back to make changes visible to all nodes.
V value = map.get(key); value.updateSomeProperty(); map.put(key, value);
cache-value is true (default is true), Hazelcast caches that returned value
for fast access in local node. Modifications done to this cached value without
putting it back to map will be visible to only local node, successive
get calls will
return the same cached value.
To reflect modifications to distributed map, you should put modified value back into map.
Collections which return values of methods such as
IMap.values, contain cloned values. These collections are NOT
backup by related Hazelcast objects.
So changes to the these are <b>NOT</b> reflected in the originals, and vice-versa.
Most of the Hazelcast operations throw an
(which is unchecked version of
if a user thread is interrupted while waiting a response.
Hazelcast uses RuntimeInterruptedException to pass InterruptedException up through interfaces
that don't have InterruptedException in their signatures. Users should be able to catch and handle
RuntimeInterruptedException in such cases as if their threads are interrupted on
a blocking operation.
Some of Hazelcast operations can throw
ConcurrentModificationException under transaction
while trying to acquire a resource, although operation signatures don't define such an exception.
Exception is thrown if resource can not be acquired in a specific time. Users should be able to catch
ConcurrentModificationException while they are using Hazelcast transactions.