Read Concern - Write Concern - Read Preference - What does it mean?

Transactions and Read Preference

• If the transaction-level read preference is unset, the transaction uses the session-level read preference.

• If transaction-level and the session-level read preference are unset, the transaction uses the client-level read preference. By default, the client-level read preference is primary.

• If the transaction-level read concern is unset, the transaction-level read concern defaults to the session-level read concern.

• If transaction-level and the session-level read concern are unset, the transaction-level read concern defaults to the client-level read concern. By default, client-level read concern is "local" for reads against the primary. See also:
• Transactions and Read Preference
• Default MongoDB Read Concerns/Write Concerns

"local"

• Read concern "local" returns the most recent data available from the node but can be rolled back.

• For transactions on sharded cluster, "local" read concern cannot guarantee that the data is from the same snapshot view across the shards. If snapshot isolation is required, use "snapshot" read concern.

"majority"

• Read concern "majority" returns data that has been acknowledged by a majority of the replica set members (i.e. data cannot be rolled back) if the transaction commits with write concern “majority”.

• If the transaction does not use write concern “majority” for the commit, the "majority" read concern provides no guarantees that read operations read majority-committed data.

• For transactions on sharded cluster, "majority" read concern cannot guarantee that the data is from the same snapshot view across the shards. If snapshot isolation is required, use "snapshot" read concern.

"snapshot"

• Read concern "snapshot" returns data from a snapshot of majority committed data if the transaction commits with write concern “majority”.

• If the transaction does not use write concern “majority” for the commit, the "snapshot" read concern provides no guarantee that read operations used a snapshot of majority-committed data.

• For transactions on sharded clusters, the "snapshot" view of the data is synchronized across shards.

Transactions and Write Concern

• If the transaction-level write concern is unset, the transaction-level write concern defaults to the session-level write concern for the commit.

• If the transaction-level write concern and the session-level write concern are unset, transaction-level write concern defaults to the client-level write concern. By default, client-level write concern is w: 1. See also Default MongoDB Read Concerns/Write Concerns.

w: 1

• Write concern w: 1 returns acknowledgement after the commit has been applied to the primary.
📒
IMPORTANT When you commit with w: 1, your transaction can be rolled back if there is a failover.

• When you commit with w: 1 write concern, transaction-level "majority" read concern provides no guarantees that read operations in the transaction read majority-committed data.

• When you commit with w: 1 write concern, transaction-level "snapshot" read concern provides no guarantee that read operations in the transaction used a snapshot of majority-committed data.

w: "majority"

• Write concern w: "majority" returns acknowledgement after the commit has been applied to a majority (M) of voting members; i.e. the commit has been applied to the primary and (M-1) voting secondaries.

• When you commit with w: "majority" write concern, transaction-level "majority" read concern guarantees that operations have read majority-committed data. For transactions on sharded clusters, this view of the majority-committed data is not synchronized across shards.

• When you commit with w: "majority" write concern, transaction-level "snapshot" read concern guarantees that operations have from a synchronized snapshot of majority-committed data.