krasserm
commented
9 years ago An initial implementation (M1) exists on branch wip-66-causal-event-delivery. In this implementation, event-sourced actors and views re-order events before delivering them to their event handler. It is assumed that an actor that handles a given event also handles all causally related events. Hence, these causally related events
- must pass all replication filters
- must be routed to that actor and
- must be handled by that actor
This is the case for some applications, such as Eventuate's operation-based CRDTs, for example. However, the above assumptions cannot be made in general because application-specific replication filters, routings and event handlers can prevent causally related events from being handled by a certain actor.
Storing events in an order that is consistent with their causal relationship can be inefficient. When giving up causal storage order, Eventuate must re-order events before delivering them in order to preserve causality on application-level.
Applications should also also be able to disable causal delivery. This is useful for actors that manage Counter or MV-Register CRDTs, for example, for which causal delivery order is not relevant. Other application-specific actors and/or views may also want to turn off causal delivery if their state update operations commute.