With MongoDB's causally consistent client sessions, different combinations of read and write concerns provide different causal consistency guarantees.
The following table lists the specific guarantees that various combinations provide:
Read Concern | Write Concern | Read own writes | Monotonic reads | Monotonic writes | Writes follow reads |
|---|---|---|---|---|---|
✅ | ✅ | ✅ | ✅ | ||
✅ | ✅ | ||||
✅ |
If you want causal consistency with data 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; in other words, 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; in other words, the write operations that request acknowledgment that the operation has been applied to a majority of the replica set's voting members.
If you want causal consistency without data durability (meaning that 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:
Example
With the above partition
Writes with
"majority"write concern can complete onPnew but cannot complete onPold.Writes with
{ w: 1 }write concern can complete on eitherPold orPnew. However, the writes toPold (as well as the writes replicated toS1) roll back once these members regain communication with the rest of the replica set.After a successful write with
"majority"write concern onPnew, causally consistent reads with"majority"read concern can observe the write onPnew,S2,andS3. The reads can also observe the write onPold andS1 once they can communicate with the rest of the replica set and sync from the other members of the replica set. Any writes made toPold and/or replicated toS1 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"
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
Note
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 1 with write concern | For item |
✅ Read own writes | Read 1 reads data from |
✅ Monotonic reads | Read 2 reads data from |
✅ Monotonic writes | Write 2 updates data on |
✅ Writes follow reads | Write 2 updates data on |
Note
Scenario 2 (Read Concern "majority" and Write Concern "majority")
Consider an alternative sequence where Read 1 with read concern "majority" routes to S 1:
Sequence | Example |
|---|---|
1. Write 1 with write concern | For item |
In this sequence, Read 1 cannot return until the majority commit point has advanced on P old. This cannot occur until P old and S 1 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 1) from the other members of the replica set.
✅ Read own writes | Read 1 reflects a state of data after Write 1, albeit after the network partition has healed and the member has sync'ed from the other members of the replica set. Read 2 reads data from |
✅ Monotonic reads | Read 2 reads data from |
✅ Monotonic writes | Write 2 updates data on |
✅ Writes follow reads | Write 2 updates data on |
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 you want
causal consistency with data durability:
❌ Read own writes ✅ Monotonic reads ❌ Monotonic writes ✅ Writes follow reads
If you want causal consistency without data durability:
✅ Read own writes ✅ Monotonic reads ✅ Monotonic writes ✅ Writes follow reads
Note
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 you want causal
consistency with data durability:
Sequence | Example |
|---|---|
1. Write 1 with write concern | For item |
In this sequence,
Read 1 cannot return until the majority commit point has advanced on
Pnew past the time of Write 1.Read 2 cannot return until the majority commit point has advanced on
Pnew past the time of Write 2.Write 1 will roll back when the network partition is healed.
➤ If you want causal consistency with data durability
❌ Read own writes | Read 1 reads data from |
✅ Monotonic reads | Read 2 reads data from |
❌ Monotonic writes | Write 2 updates data on |
✅ Writes follow reads | Write 2 updates data on |
➤ If you want causal consistency without data durability
✅ Read own writes | Read 1 reads data from |
✅ Monotonic reads | Read 2 reads data from |
✅ Monotonic writes | Write 2 updates data on |
✅ Writes follow reads | Write 2 updates data on |
Note
Scenario 4 (Read Concern "majority" and Write Concern {w: 1})
Consider an alternative sequence where Read 1 with read concern "majority" routes to S 1:
Sequence | Example |
|---|---|
1. Write 1 with write concern | For item |
In this sequence:
- Read 1 cannot return until the majority commit point has advanced on
S1. This cannot occur untilPold andS1 can communicate with the rest of the replica set. At which time,Pold has stepped down (if not already), Write 1 is rolled back fromPold andS1, and the two members sync from the other members of the replica set.
➤ If you want causal consistency with data durability
❌ Read own writes | The data read by Read 1 doesn't reflect the results of Write 1, which has rolled back. |
✅ Monotonic reads | Read 2 reads data from |
❌ Monotonic writes | Write 2 updates data on |
✅ Writes follow reads | Write 2 updates data on |
➤ If you want causal consistency without data durability
✅ Read own writes | Read 1 returns data that reflects the final result of Write 1 since Write 1 ultimately rolls back. |
✅ Monotonic reads | Read 2 reads data from |
✅ Monotonic writes | Write 2 updates data on |
✅ Writes follow reads | Write 2 updates data on |
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.
Note
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 |
|---|---|
For item |
❌ Read own writes | Read 2 reads data from |
❌ Monotonic reads | Read 2 reads data from |
❌ Monotonic writes | Write 2 updates data on |
❌ Write follow read | Write 2 updates data on |
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.
Note
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 1 with write concern | For item |
❌ Read own writes. | Read 1 reads data from |
❌ Monotonic reads. | Read 2 reads data from |
✅ Monotonic writes | Write 2 updates data on |
❌ Write follow read. | Write 2 updates data on |