How do read concern and write concern apply inside a MongoDB multi-document transaction?

## Concerns move up a level Outside a transaction, each operation carries its own read concern and write concern. Inside one, they belong to the transaction. You set them on `startTransaction()` (or pass them to `withTransaction()`), and every operation in the transaction inherits them. Attaching a write concern to a write *inside* an open transaction is rejected — the write has no independent acknowledgement to wait for. ```javascript session.startTransaction({ readConcern: { level: "snapshot" }, writeConcern: { w: "majority" }, maxCommitTimeMS: 5000 }); ``` ## Write concern applies to the commit This is the mental model shift. Writes made inside a transaction are staged; nothing is visible to other clients until commit. The transaction's write concern therefore describes the **commit**: with `w: "majority"` the driver waits until the commit has been acknowledged by a majority of the replica set, meaning the transaction's effects will survive a failover. With a weaker concern the commit returns sooner and the whole transaction can be rolled back by a subsequent election, exactly as an ordinary write can be. A practical corollary: a transaction that writes ten documents pays the majority-acknowledgement latency once, at commit, rather than ten times. That is one of the few ways in which a transaction is cheaper than the equivalent loop of individual majority writes. Abort has a write concern too, and `maxCommitTimeMS` caps how long the driver waits for the commit before it returns a timeout — which, importantly, arrives labelled as an unknown commit result, not as a failure. ## Read concern governs all reads in the transaction Three levels are supported: `local`, `majority` and `snapshot`. `linearizable` and `available` are not permitted inside a transaction. - **`snapshot`** reads from a single snapshot of majority-committed data. All reads in the transaction see the same point in time, and on a sharded cluster the participating shards use a common cluster time, so a multi-shard read is coherent. This is the level to reach for when the transaction's correctness depends on reading a consistent world. - **`majority`** reads data that has been acknowledged by a majority. Inside a transaction this level only gives its full guarantee when the transaction goes on to commit with `w: "majority"`; a transaction that reads `majority` and commits weakly does not carry a majority-durability guarantee end to end. - **`local`** reads the most recent data on the node without the majority requirement. It is the cheapest and, on a sharded cluster, gives no cross-shard point-in-time alignment. In all cases the transaction reads its **own** writes: an operation later in the transaction sees the documents earlier operations in the same transaction modified, even though no other client can. ## Reads come from the primary Multi-document transactions read from the primary. Read preference inside a transaction must be primary, and setting `secondary` or `secondaryPreferred` produces an error rather than silently downgrading. Teams that route analytics traffic to secondaries sometimes assume they can wrap a large read in a transaction to get a snapshot cheaply on a secondary — they cannot; the transaction pins load onto the primary. ## Where this goes wrong in production **Assuming per-operation concerns still apply.** Code that carefully sets `w: "majority"` on each write and is later wrapped in a transaction either errors or, if the concerns are stripped, silently commits under the transaction's default — which may be weaker than the author intended. Set them on the transaction and review them there. **Assuming `snapshot` is free.** Holding a snapshot for the life of the transaction keeps older versions pinned, which competes with cache and with cleanup. Long transactions at `snapshot` are the ones most likely to hurt. **Assuming an unknown commit result means failure.** A commit that times out or loses its connection is *unknown*, not failed. The correct response is to re-send `commitTransaction()` on the same session; treating it as a failure and re-running the work risks doing it twice. **Assuming a transaction upgrades durability automatically.** Read concern and write concern are still yours to choose. A transaction gives atomicity and isolation; it does not silently give you majority durability unless you ask for it. ## What to say in an interview Name the level shift (concerns belong to the transaction), state that write concern lands on the commit, name the three permissible read concerns and what `snapshot` buys, mention the primary-only read rule, and close with the coupling: `majority` reads only mean what you think they mean if the commit is also `majority`.