- Type Parameters:
V- the (deserialized) type of the merging value
T- the type of the required merging value, e.g. a simple
MergingValue<V>or a composition like
MergingEntry<String, V> & MergingHits & MergingLastAccessTime
R- the type of the merged value as returned by
- All Superinterfaces:
- All Known Implementing Classes:
public interface SplitBrainMergePolicy<V,T extends MergingValue<V>,R> extends DataSerializable
The values of merging and existing
always in the in-memory format of the backing data structure.
This can be a serialized format, so the content cannot be
processed without deserialization. For most merge policies
this will be fine, since the key or value are not used.
The deserialization is not done eagerly for two main reasons:
- The deserialization is quite expensive and should be avoided, if the result is not needed.
- There is no need to locate classes of stored entries
on the server side, when the entries are not deserialized.
So you can put entries from a client by using
InMemoryFormat.BINARYwith a different classpath on client and server. In this case a deserialization could throw a
MergingEntry.getKey(), which will deserialize the data lazily.
A merge policy can implement
HazelcastInstanceAware to get the
HazelcastInstance injected. This can be used to retrieve the
user context via
HazelcastInstance.getUserContext(), which is
an easy way to get user dependencies that are otherwise hard to obtain.
A merge policy can also implement
to get an instance of
mergeSelects the value of either the merging or the existing
MergingValuewhich should be merged.