Package org.apache.pekko.cluster.ddata

Interface FastMerge

All Known Implementing Classes:
GCounter, GSet, ORSet
public interface FastMerge
INTERNAL API

Optimization for add/remove followed by merge and merge should just fast forward to the new instance.

It's like a cache between calls of the same thread, you can think of it as a thread local. The Replicator actor invokes the user's modify function, which returns a new ReplicatedData instance, with the ancestor field set (see for example the add method in ORSet). Then (in same thread) the Replication calls merge, which makes use of the ancestor field to perform quick merge (see for example merge method in ORSet).

It's not thread safe if the modifying function and merge are called from different threads, i.e. if used outside the Replicator infrastructure, but the worst thing that can happen is that a full merge is performed instead of the fast forward merge.

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    ancestor_$eq(FastMerge x$1)
     
    FastMerge
    assignAncestor(org.apache.pekko.cluster.ddata.ReplicatedData.T newData)
    INTERNAL API: should be called from "updating" methods, and `resetDelta`
    FastMerge
    clearAncestor()
    INTERNAL API: should be called from merge
    boolean
    isAncestorOf(org.apache.pekko.cluster.ddata.ReplicatedData.T that)
    INTERNAL API: should be used from merge

  • Method Details

    • ancestor_$eq

      void ancestor_$eq(FastMerge x$1)

    • assignAncestor

      FastMerge assignAncestor(org.apache.pekko.cluster.ddata.ReplicatedData.T newData)
      INTERNAL API: should be called from "updating" methods, and `resetDelta`

    • clearAncestor

      FastMerge clearAncestor()
      INTERNAL API: should be called from merge

    • isAncestorOf

      boolean isAncestorOf(org.apache.pekko.cluster.ddata.ReplicatedData.T that)
      INTERNAL API: should be used from merge