If there is zero conflict, then only one node is writing to that object; however a fork is still possible in Raft (and by extension, Federated) with both raft-c and raft-i (as implemented) by executing two writes in sequence before a single AppendEntries.
In our implementation of raft-i, all writes are remote-writes, meaning that nothing goes into the local log except as the result of an append entries. Therefore two writes before an AE will both read the same latest version, and the second write is therefore a fork.
Because the leader is aggregating AE messages, it is therefore possible that the time until the next AE > round trip message latency.
I'll have to add a secondary local cache so that back to back writes are appropriately stored until AE.
Forks in zero conflict model:
If there is zero conflict, then only one node is writing to that object; however a fork is still possible in Raft (and by extension, Federated) with both raft-c and raft-i (as implemented) by executing two writes in sequence before a single AppendEntries.
In our implementation of raft-i, all writes are remote-writes, meaning that nothing goes into the local log except as the result of an append entries. Therefore two writes before an AE will both read the same latest version, and the second write is therefore a fork.
Because the leader is aggregating AE messages, it is therefore possible that the time until the next AE > round trip message latency.
I'll have to add a secondary local cache so that back to back writes are appropriately stored until AE.