These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
I can't understand when that updated version vector could arrive between a ReplicationRead and its corresponding ReplicationReadSuccess.
It may be updated during writes by a replication connection in the opposite direction.
Why EventLog.replicaVersionVectors is needed if ReplicationRead includes the currentVersionVector of the target?
See previous answer.
Why is fromSequenceNr included in ReplicationRead?
This is the tracked replication progress at target location. For example, after having replicated events 1-100 you want the next replication batch to start from 101 which is tracked with the fromSequenceNr.
I assumed that ReplicationRead only included currentVersionVector and then all (1) the events were causaly filtered
Replication read times would then linearly increase with the size of the log which must be avoided, of course.
I don't see what will be the benefit of causal stability
A causal stability indicator is needed for pure op-based CRDTs if you want to delete events from their local event logs. If you keep the whole op history persistent in local event logs then pure op-based CRDTs can be implemented without the garbage collection procedure described in the paper, I think.