RavenDB guarantees that modifications made in the same transaction will always be replicated
to the destination in a single batch and won't be broken into separate batches.
This is true for both the internal-replication and the replication-tasks.
Replication & cluster-wide transactions
A cluster-wide transaction, which is implemented by the Raft Protocol,
is either persisted on all database group nodes or rolled back on all upon failure.
After a cluster consensus is reached, the Raft command to be executed is propagated to all nodes.
When the command is executed locally on a node, if the items that are persisted are of the type that replicates,
then the node will replicate them to the other nodes via the replication process.
A node that receives such replication will accept this write,
unless it has already committed it through a raft command it received before.
Transaction boundaries in single-node transactions
If there are several document modifications in the same transaction they will be sent in the same replication
batch, keeping the transaction boundary on the destination as well.
However, when a document is modified in two separate transactions,
and if replication of the 1st transaction has not yet occurred,
then that document will Not be sent when the 1st transaction is replicated,
it will be sent with the 2nd transaction.
If you care about all the modifications that were done then enable revisions:
When a revision is created for a document it is written as part of the same transaction as the document.
The revision is then replicated along with the document in the same indivisible batch.
How revisions replication help data consistency
Consider a scenario in which two documents,
Users/2, are created in the same transaction,
Users/2 is modified in a different transaction.
Users/2 be replicated?
When RavenDB creates replication batches, it keeps the
transaction boundary by always sending documents that were modified in the same transaction,
in the same batch.
In our scenario, however,
Users/2 was modified after its creation, it
is now recognized by its Etag as a part of a different transaction than
Users/1, and the two documents may be replicated in two different
Users/1 first and
If this happens,
Users/1 will be replicated to the destination without
though they were created in the same transaction, causing a data inconsistency that
will persist until the arrival of
The scenario will be different if revisions are enabled.
In this case the creation of
Users/2 will also create revisions
for them both. These revisions will continue to carry the Etag given to them
at their creation, and will be replicated in the same batch.
When the batch arrives at the destination, data consistency will be kept:
Users/1 will be stored, and so will the
Users/2 revision, that will become