public interface IdGenerator extends DistributedObject
longIDs in a cluster, under normal operating scenarios.
In theory a
IAtomicLong.incrementAndGet() could be used to provide the same functionality.
The big difference is that the incrementAndGet requires one or more remote calls for every invocation and therefor
is a performance and scalability bottleneck. The IdGenerator uses an
IAtomicLong under the hood, but instead of
doing remote call for every call to
newId(), it does it less frequently. It checks out a chunk, e.g. 1..1000
and as long as it has not yet consumed all the IDs in its chunk, then no remote call is done.
It can be that IDs generated by different cluster members will get out of order because each member will get its own chunk. It can be that member 1 has chunk 1..1000 and member 2 has 1001..2000. Therefore, member 2 will automatically have IDs that are out of order with the IDs generated by member 1.
It should be noted that IdGenerator does not guarantee unique IDs in a split brain situation. During a split brain,
different partitions of the cluster may have the primary or back-up, and will therefore continue in their respective
clusters from the last known value. Other partitions of the cluster may not have the original primary nor the
back-up, in which case the
IdGenerator will be created as new and initialised as per the provided
When a cluster heals after a split brain, a default large side merge takes place for the
that keeps track of the last issued block of IDs, therefore it is possible that already issued IDs could be issued
again after the cluster is repaired. As a precaution when in a new record insert situation try to detect if the key
already exists and then grab another, possibly executing this logic only after a known split brain merge has occurred.
Care should be taken if you are using the IdGenerator to provide keys for
ICache, as after split brain it could be possible for two unique values to share
the same key. When a
MapMergePolicy is applied, one of these unique values will
have to be discarded. Unless configured the default merge policy is
It is NOT RECOMMENDED to use
IdGenerator to provide keys that are also used as unique identifiers in
underlying persistent storage, for example a
IMap that writes to a Relational Database using
|Modifier and Type||Method and Description|
Tries to initialize this IdGenerator instance with the given ID.
Generates and returns a cluster-wide unique ID.
boolean init(long id)
The first generated ID will be 1 greater than ID.
trueif initialization succeeded,
falseif ID is less than 0.
Generated IDs are guaranteed to be unique for the entire cluster as long as the cluster is live. If the cluster restarts, then ID generation will start from 0.
Copyright © 2018 Hazelcast, Inc.. All Rights Reserved.