<!-- llms-explorer concept facts · https://llms-explorer.com/tree/multi-document-transactions/ · pack 2026-10-20 · ~1451 tokens -->

# Multi-Document Transactions

> Source-anchored research for Multi-Document Transactions. Run status: COMPLETED.

Parent: [MongoDB Transactions](https://llms-explorer.com/tree/mongodb-transactions/) · 5 facets · 14 facts · page: https://llms-explorer.com/tree/multi-document-transactions/

## Structure and components

- Transaction-level readConcern snapshot provides a point-in-time view. MongoDB guarantees that the snapshot contains majority-committed data only when the transaction commits with writeConcern majority. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/transactions.md)

## How it works

- Jepsen's 2020 analysis of MongoDB 4.2.6 reports read skew, cyclic information flow, duplicate writes, and internal consistency violations under its strongest tested read and write concerns. In its 2020-05-26 update, Jepsen says MongoDB attributed the observed anomalies to a transaction-retry bug and scheduled a patch for 4.2.8; this is historical evidence scoped to the tested build. (low confidence) (verified as of 2020-05-26) — [source](https://jepsen.io/analyses/mongodb-4.2.6)
- MongoDB's current documentation says a transaction-level read concern of snapshot provides a majority-committed snapshot guarantee only when the transaction commits with write concern majority. Read concern settings on a database or collection are ignored inside the transaction. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/reference/read-concern.md)

## Problems, failure modes and limitations

- MongoDB's current production documentation sets a default transaction runtime limit of less than one minute; transactions that exceed it expire and are aborted by periodic cleanup. The server parameter transactionLifetimeLimitSeconds can change the limit. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/transactions-production-consideration.md)

## Comparisons and alternatives

- MongoDB notes that single-document operations are already atomic and therefore meet many practical use cases; multi-document transactions add performance cost compared with single-document writes. Percona also describes more work and a wider conflict window as transaction operations span more documents or run longer. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/transactions.md)

## Facts and statements

- MongoDB single-document writes are atomic. A multi-document transaction extends that atomicity to a unit of operations that can touch multiple documents, collections, and databases; the transaction commits all its changes or aborts them as a unit. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/transactions.md)
- Outside an explicit transaction, a multi-document write such as updateMany modifies each document atomically but is not atomic as a whole; other operations can interleave while it runs. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/read-isolation-consistency-recency.md)
- Driver APIs associate a transaction with a session. Every operation that should participate must receive that session, and the application commits or aborts the transaction, either directly or through a driver callback API. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/drivers/java/sync/current/crud/transactions/multi-doc-acid-transactions.md)
- MongoDB Server 4.0 and later supports ACID transactions across multiple documents, collections, and databases. (high confidence) — [source](https://www.mongodb.com/docs/drivers/java/sync/current/crud/transactions/multi-doc-acid-transactions.md)
- MongoDB Jira issue SERVER-84760 records that before version 7.0, a transaction using readConcern snapshot could observe a state that never existed if an outside operation dropped or renamed a collection between transaction reads. The issue record says this behavior did not reproduce on version 7.0 and later. (low confidence) (verified as of 2024-06-19) — [source](https://jira.mongodb.org/browse/SERVER-84760)
- MongoDB transactions group operations across multiple documents and collections into one unit: commit applies the changes atomically, while abort discards the transaction's changes. MongoDB states that its ACID guarantees depend on the configured read and write concerns. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/transactions.md)
- A driver starts a client session for a transaction and passes that session to every operation in the transaction, then commits or aborts the unit. MongoDB's callback API retries transactions for selected TransientTransactionError and UnknownTransactionCommitResult errors. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/transactions.md)
- If an outside write modifies a document that an active transaction later tries to modify, MongoDB aborts the transaction with a write conflict. The callback API retries selected errors; applications using the core transaction API must handle conflicts and other errors that the driver does not retry. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/manual/core/transactions-production-consideration.md)
- Jepsen reported that its 2020 tests of MongoDB 4.2.6 found histories violating snapshot isolation even with snapshot read concern and majority write concern. A May 26, 2020 report update says MongoDB identified a transaction retry bug it believed caused the anomalies and scheduled a fix for 4.2.8; this historical result does not establish behavior in later releases. (medium confidence) (verified as of 2020-05-26) — [source](https://jepsen.io/analyses/mongodb-4.2.6)
