# Read concern and causal consistency with secondary reads > Source-anchored research for Read concern and causal consistency with secondary reads. Run status: COMPLETED. Parent: [MongoDB Query Shape Optimization: Sort, Pagination, Operators and Sharded Targeting](https://llms-explorer.com/tree/mongodb-query-shape-optimization-sort-pagination-operators-and-sharded-targeting/) · 4 facets · 17 facts · page: https://llms-explorer.com/tree/read-concern-and-causal-consistency-with-secondary-reads/ ## How it works - Read preference selects eligible replica-set members; directing reads to secondaries can return stale data because replication from the primary is asynchronous. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference.md) - For durable causal consistency, execute dependent operations in a causally consistent client session with majority read concern and majority write concern. This combination guarantees read-your-writes, monotonic reads, monotonic writes, and writes-follow-reads, including when reads use secondaries. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns.md) ## Problems, failure modes and limitations - A causally consistent read cannot depend on an unacknowledged w:0 write because the session receives no operation time for that write. (high confidence) — [source](https://specifications.readthedocs.io/en/latest/causal-consistency/causal-consistency/) ## Comparisons and alternatives - MongoDB 8.0 changed majority-write acknowledgment to follow oplog persistence rather than completion of secondary application. An immediate secondary read outside a causally consistent session can therefore miss the acknowledged update. (medium confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/reference/write-concern.md) - Majority read concern uses a committed timestamped snapshot rather than polling every replica for the latest value. Without an additional causal-time requirement it usually need not wait for new writes, although snapshot availability and replication lag can cause blocking. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) ## Facts and statements - Majority read concern alone does not mean reading the latest primary state: it can return an older majority-committed snapshot on the selected member. (high confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/README.md) - A majority write followed in the same causal session by a majority read with secondary read preference reflects the preceding write; if the selected secondary has not reached the dependency time, the read waits. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md) - Drivers track operationTime in the client session and send it as readConcern.afterClusterTime on subsequent supported causally consistent commands. They also gossip clusterTime; applications should use the session API to carry this causal context. (high confidence) — [source](https://specifications.readthedocs.io/en/latest/causal-consistency/causal-consistency/) - Applications must serialize operations within a client session. To preserve dependencies across sessions, explicitly advance the receiving session operation time and cluster time from the originating session. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md) - Causal consistency does not isolate a session from concurrent outside writes. A subsequent read may include intervening writes, so these guarantees should not be treated as snapshot isolation or a guarantee of the latest unrelated write. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md) - Do not assume that enabling causal sessions makes weaker concern settings durable: MongoDB documents partial guarantees for weaker combinations, and Jepsen historically found that causal sessions with weaker read/write concerns could violate expected causal behavior. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns.md) - Independent Internetware research tested MongoDB 4.2.3 using formal CC, CCv, and CM checking and reported preliminary results supporting the majority-read/majority-write requirements under faults; this is historical test evidence, not validation of current server versions. (low confidence) — [source](https://hengxin.github.io/papers/2021-Internetware-MongoDB-CCC.pdf) - Read-containing multi-document transactions must use primary read preference; a causal session supporting secondary reads does not make a secondary eligible for such transaction reads. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/read-preference.md) - Read preference selects eligible replica-set members; read concern controls the data a selected member may return. A secondary can lag the primary, and majority read concern alone does not guarantee the newest write is visible. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md) - A causally dependent secondary read may wait for the secondary to reach the required causal time. Causal consistency trades waiting for dependency order; it does not make asynchronous replication instantaneous. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns.md) - Operations in different client sessions need an explicit causal handoff: advance the receiving session's operation time and cluster time from the producing session. An acknowledgment or application notification alone does not transfer that session context. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md) - Do not assume that enabling a causal session repairs weaker concerns. MongoDB documents fewer durable guarantees with local reads or w:1 writes; Jepsen's 2018 tests of MongoDB 3.6.4 found causal anomalies under sub-majority settings. Those historical tests do not establish a present-version defect. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns.md)