Causal Consistency and Read and Write Concerns¶

With MongoDB’s causally consistent client sessions, different combinations of read and write concerns provide different causal consistency guarantees. When causal consistency is defined to imply durability, then the following table lists the specific guarantees provided by the various combinations:

Read Concern	Write Concern	Read own writes	Monotonic reads	Monotonic writes	Writes follow reads
`"majority"`	`"majority"`	✅	✅	✅	✅
`"majority"`	`{ w: 1 }`		✅		✅
`"local"`	`{ w: 1 }`
`"local"`	`"majority"`			✅

If causal consistency implies durability, then, as seen from the table, only read operations with "majority" read concern and write operations with "majority" write concern can guarantee all four causal consistency guarantees. That is, causally consistent client sessions can only guarantee causal consistency for:

Read operations with "majority" read concern; i.e. the read operations that return data that has been acknowledged by a majority of the replica set members and is durable.
Write operations with "majority" write concern; i.e. the write operations that request acknowledgement that the operation has been applied to a majority of the replica set’s voting members.

If causal consistency does not imply durability (i.e. writes may be rolled back), then write operations with { w: 1 } write concern can also provide causal consistency.

Note

The other combinations of read and write concerns may also satisfy all four causal consistency guarantees in some situations, but not necessarily in all situations.

The read concern "majority" and write concern "majority" ensure that the four causal consistency guarantees hold even in circumstances (such as with a network partition) where two members in a replica set transiently believe that they are the primary. And while both primaries can complete writes with { w: 1 } write concern, only one primary will be able to complete writes with "majority" write concern.

For example, consider a situation where a network partition divides a five member replica set:

Network partition: new primary elected on one side but old primary has not stepped down yet.

With the above partition

Writes with "majority" write concern can complete on P_new but cannot complete on P_old.
Writes with { w: 1 } write concern can complete on either P_old or P_new. However, the writes to P_old (as well as the writes replicated to S₁) roll back once these members regain communication with the rest of the replica set.
After a successful write with "majority" write concern on P_new, causally consistent reads with "majority" read concern can observe the write on P_new, S₂,and S₃. The reads can also observe the write on P_old and S₁ once they can communicate with the rest of the replica set and sync from the other members of the replica set. Any writes made to P_old and/or replicated to S₁ during the partition are rolled back.

Scenarios¶

To illustrate the read and write concern requirements, the following scenarios have a client issue a sequence of operations with various combination of read and write concerns to the replica set:

Read Concern "majority" and Write concern "majority"
Read Concern "majority" and Write concern {w: 1}
Read Concern "local" and Write concern "majority"
Read Concern "local" and Write concern {w: 1}

Read Concern `"majority"` and Write concern `"majority"`¶

The use of read concern "majority" and write concern "majority" in a causally consistent session provides the following causal consistency guarantees:

✅ Read own writes ✅ Monotonic reads ✅ Monotonic writes ✅ Writes follow reads

Scenario 1 (Read Concern “majority” and Write Concern “majority”)

During the transient period with two primaries, because only P_new can fulfill writes with { w: "majority" } write concern, a client session can issue the following sequence of operations successfully:

Sequence	~~Example~~示例
1. Write₁ with write concern `"majority"` to `P`_new 2. Read₁ with read concern `"majority"` to `S`₂ 3. Write₂ with write concern `"majority"` to `P`_new 4. Read₂ with read concern `"majority"` to `S`₃	For item `A`, update `qty` to `50`. Read item `A`. For items with `qty` less than or equal to `50`, update `restock` to `true`. Read item `A`.

State of data with two primaries using read concern majority and write concern majority

✅ Read own writes	Read₁ reads data from `S`₂ that reflects a state after Write₁. Read₂ reads data from `S`₁ that reflects a state after Write1₁ followed by Write₂.
✅ Monotonic reads	Read₂ reads data from `S`₃ that reflects a state after Read₁.
✅ Monotonic writes	Write₂ updates data on `P`_new that reflects a state after Write₁.
✅ Writes follow reads	Write₂ updates data on `P`_new that reflects a state of the data after Read₁ (i.e. an earlier state reflects the data read by Read₁).

Scenario 2 (Read Concern “majority” and Write Concern “majority”)

Consider an alternative sequence where Read₁ with read concern "majority" routes to S₁:

Sequence	~~Example~~示例
1. Write₁ with write concern `"majority"` to `P`_new 2. Read₁ with read concern `"majority"` to `S`₁ 3. Write₂ with write concern `"majority"` to `P`_new 4. Read₂ with with read concern `"majority"` to `S`₃	For item `A`, update `qty` to `50`. Read item `A`. For items with `qty` less than or equal to `50`, update `restock` to `true`. Read item `A`.

In this sequence, Read₁ cannot return until the majority commit point has advanced on P_old. This cannot occur until P_old and S₁ can communicate with the rest of the replica set; at which time, P_old has stepped down (if not already), and the two members sync (including Write₁) from the other members of the replica set.

✅ Read own writes	Read₁ reflects a state of data after Write1₁, albeit after the network partition has healed and the member has sync’ed from the other members of the replica set. Read₂ reads data from `S`₃ that reflects a state after Write1₁ followed by Write₂.
✅ Monotonic reads	Read₂ reads data from `S`₃ that reflects a state after Read₁ (i.e. an earlier state is reflected in the data read by Read₁).
✅ Monotonic writes	Write₂ updates data on `P`_new that reflects a state after Write₁.
✅ Writes follow reads	Write₂ updates data on `P`_new that reflects a state of the data after Read₁ (i.e. an earlier state reflects the data read by Read₁).

Read Concern `"majority"` and Write concern `{w: 1}`¶

The use of read concern "majority" and write concern { w: 1 } in a causally consistent session provides the following causal consistency guarantees if causal consistency implies durability:

❌ Read own writes ✅ Monotonic reads ❌ Monotonic writes ✅ Writes follow reads

If causal consistency does not imply durability:

✅ Read own writes ✅ Monotonic reads ✅ Monotonic writes ✅ Writes follow reads

Scenario 3 (Read Concern “majority” and Write Concern {w: 1})

During the transient period with two primaries, because both P_old and P_new can fulfill writes with { w: 1 } write concern, a client session could issue the following sequence of operations successfully but not be causally consistent if causal consistency implies durability:

Sequence	~~Example~~示例
1. Write₁ with write concern `{ w: 1 }` to `P`_old 2. Read₁ with read concern `"majority"` to `S`₂ 3. Write₂ with write concern `{ w: 1 }` to `P`_new 4. Read₂ with with read concern `"majority"` to `S`₃	For item `A`, update `qty` to `50`. Read item `A`. For items with `qty` less than or equal to `50`, update `restock` to `true`. Read item `A`.

State of data with two primaries using read concern majority and write concern 1

In this sequence,

Read₁ cannot return until the majority commit point has advanced on P_new past the time of Write₁.
Read₂ cannot return until the majority commit point has advanced on P_new past the time of Write₂.
Write₁ will roll back when the network partition is healed.

➤ If causal consistency implies durability

❌ Read own writes	Read₁ reads data from `S`₂ that does not reflect a state after Write₁.
✅ Monotonic reads	Read₂ reads data from `S`₃ that reflects a state after Read₁ (i.e. an earlier state is reflected in the data read by Read₁).
❌ Monotonic writes	Write₂ updates data on `P`_new that does not reflect a state after Write₁.
✅ Writes follow reads	Write₂ updates data on `P`_new that reflects a state after Read₁ (i.e. an earlier state reflects the data read by Read₁).

➤ If causal consistency does not imply durability

✅ Read own writes	Read₁ reads data from `S`₂ returns data that reflects a state equivalent to Write₁ followed by rollback of Write₁.
✅ Monotonic reads	Read₂ reads data from `S`₃ that reflects a state after Read₁ (i.e. an earlier state is reflected in the data read by Read₁).
✅ Monotonic writes	Write₂ updates data on `P`_new that is equivalent to after Write₁ followed by rollback of Write₁.
✅ Writes follow reads	Write₂ updates data on `P`_new that reflects a state after Read₁ (i.e. whose earlier state reflects the data read by Read₁).

Scenario 4 (Read Concern “majority” and Write Concern {w: 1})

Consider an alternative sequence where Read₁ with read concern "majority" routes to S₁:

Sequence	~~Example~~示例
1. Write₁ with write concern `{ w: 1 }` to `P`_old 2. Read₁ with read concern `"majority"` to `S`₁ 3. Write₂ with write concern `{ w: 1 }` to `P`_new 4. Read₂ with with read concern `"majority"` to `S`₃	For item `A`, update `qty` to `50`. Read item `A`. For items with `qty` less than or equal to `50`, update `restock` to `true`. Read item `A`.

In this sequence:

Read₁ cannot return until the majority commit point has advanced on S₁. This cannot occur until P_old and S₁ can communicate with the rest of the replica set. At which time, P_old has stepped down (if not already), Write₁ is rolled back from P_old and S₁, and the two members sync from the other members of the replica set.

➤ If causal consistency implies durability

❌ Read own writes	The data read by Read₁ does not reflect the results of Write₁, which has rolled back.
✅ Monotonic reads	Read₂ reads data from `S`₃ that reflects a state after Read₁ (i.e. whose earlier state reflects the data read by Read₁).
❌ Monotonic writes	Write₂ updates data on `P`_new that does not reflect a state after Write₁, which had preceded Write₂ but has rolled back.
✅ Writes follow reads	Write₂ updates data on `P`_new that reflects a state after Read₁ (i.e. whose earlier state reflects the data read by Read₁).

➤ If causal consistency does not imply durability

✅ Read own writes	Read₁ returns data that reflects the final result of Write₁ since Write₁ ultimately rolls back.
✅ Monotonic reads	Read₂ reads data from `S`₃ that reflects a state after Read₁ (i.e. an earlier state reflects the data read by Read₁).
✅ Monotonic writes	Write₂ updates data on `P`_new that is equivalent to after Write₁ followed by rollback of Write₁.
✅ Writes follow reads	Write₂ updates data on `P`_new that reflects a state after Read₁ (i.e. an earlier state reflects the data read by Read₁).

Read Concern `"local"` and Write concern `{w: 1}`¶

The use of read concern "local" and write concern { w: 1 } in a causally consistent session cannot guarantee causal consistency.

❌ Read own writes ❌ Monotonic reads ❌ Monotonic writes ❌ Writes follow reads

This combination may satisfy all four causal consistency guarantees in some situations, but not necessarily in all situations.

Scenario 5 (Read Concern “local” and Write Concern {w: 1})

During this transient period, because both P_old and P_new can fulfill writes with { w: 1 } write concern, a client session could issue the following sequence of operations successfully but not be causally consistent:

Sequence	~~Example~~示例
1. Write₁ with write concern `{ w: 1 }` to `P`_old 2. Read₁ with read concern `"local"` to `S`₁ 3. Write₂ with write concern `{ w: 1 }` to `P`_new 4. Read₂ with read concern `"local"` to `S`₃	For item `A`, update `qty` to `50`. Read item `A`. For items with `qty` less than or equal to `50`, update `restock` to `true`. Read item `A`.

State of data with two primaries using read concern local and write concern 1

❌ Read own writes	Read₂ reads data from `S`₃ that only reflects a state after Write₂ and not Write₁ followed by Write₂.
❌ Monotonic reads	Read₂ reads data from `S`₃ that does not reflect a state after Read₁ (i.e. an earlier state does not reflect the data read by Read₁).
❌ Monotonic writes	Write₂ updates data on `P`_new that does not reflect a state after Write₁.
❌ Write follow read	Write₂ updates data on `P`_new that does not reflect a state after Read₁ (i.e. an earlier state does not reflect the data read by Read₁).

Read Concern `"local"` and Write concern `"majority"`¶

The use of read concern "local" and write concern "majority" in a causally consistent session provides the following causal consistency guarantees:

❌ Read own writes ❌ Monotonic reads ✅ Monotonic writes ❌ Writes follow reads

This combination may satisfy all four causal consistency guarantees in some situations, but not necessarily in all situations.

Scenario 6 (Read Concern “local” and Write Concern “majority”)

During this transient period, because only P_new can fulfill writes with { w: "majority" } write concern, a client session could issue the following sequence of operations successfully but not be causally consistent:

Sequence	~~Example~~示例
1. Write₁ with write concern `"majority"` to `P`_new 2. Read₁ with read concern `"local"` to `S`₁ 3. Write₂ with write concern `"majority"` to `P`_new 4. Read₂ with read concern `"local"` to `S`₃	For item `A`, update `qty` to `50`. Read item `A`. For items with `qty` less than or equal to `50`, update `restock` to `true`. Read item `A`.

State of data with two primaries using read concern local and write concern majority

❌ Read own writes.	Read₁ reads data from `S`₁ that does not reflect a state after Write1₁.
❌ Monotonic reads.	Read₂ reads data from `S`₃ that does not reflect a state after Read₁ (i.e. an earlier state does not reflect the data read by Read₁).
✅ Monotonic writes	Write₂ updates data on `P`_new that reflects a state after Write₁.
❌ Write follow read.	Write₂ updates data on `P`_new that does not reflect a state after Read₁ (i.e. an earlier state does not reflect the data read by Read₁).

Causal Consistency and Read and Write Concerns¶

Scenarios¶

Read Concern "majority" and Write concern "majority"¶

Read Concern "majority" and Write concern {w: 1}¶

Read Concern "local" and Write concern {w: 1}¶

Read Concern "local" and Write concern "majority"¶

Read Concern `"majority"` and Write concern `"majority"`¶

Read Concern `"majority"` and Write concern `{w: 1}`¶

Read Concern `"local"` and Write concern `{w: 1}`¶

Read Concern `"local"` and Write concern `"majority"`¶