Read Isolation, Consistency, and Recency¶
Depending on the read concern, clients can see the results of writes before the writes are durable:
- Regardless of a write's write concern, other
"available"read concern can see the result of a write operation before the write operation is acknowledged to the issuing client.
- Clients using
"available"read concern can read data which may be subsequently rolled back during replica set failovers.
For operations in a multi-document transaction, when a transaction commits, all data changes made in the transaction are saved and visible outside the transaction. That is, a transaction will not commit some of its changes while rolling back others.
Until a transaction commits, the data changes made in the transaction are not visible outside the transaction.
However, when a transaction writes to multiple shards, not all
outside read operations need to wait for the result of the committed
transaction to be visible across the shards. For example, if a
transaction is committed and write 1 is visible on shard A but write
2 is not yet visible on shard B, an outside read at read concern
"local" can read the results of write 1 without
seeing write 2.
Read uncommitted is the default isolation level and applies to
mongod standalone instances as well as to replica sets and
Read Uncommitted And Single Document Atomicity¶
Write operations are atomic with respect to a single document; i.e. if a write is updating multiple fields in the document, a read operation will never see the document with only some of the fields updated. However, although a client may not see a partially updated document, read uncommitted means that concurrent read operations may still see the updated document before the changes are made durable.
With a standalone
mongod instance, a set of read and write
operations to a single document is serializable. With a replica set,
a set of read and write operations to a single document is serializable
only in the absence of a rollback.
Read Uncommitted And Multiple Document Write¶
When a single write operation (e.g.
db.collection.updateMany()) modifies multiple documents,
the modification of each document is atomic, but the operation as a
whole is not atomic.
When performing multi-document write operations, whether through a single write operation or multiple write operations, other operations may interleave.
For situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports multi-document transactions:
- In version 4.0, MongoDB supports multi-document transactions on replica sets.
- In version 4.2, MongoDB introduces distributed transactions, which adds support for multi-document transactions on sharded clusters and incorporates the existing support for multi-document transactions on replica sets.
For details regarding transactions in MongoDB, see the Transactions page.
In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transactions should not be a replacement for effective schema design. For many scenarios, the denormalized data model (embedded documents and arrays) will continue to be optimal for your data and use cases. That is, for many scenarios, modeling your data appropriately will minimize the need for multi-document transactions.
For additional transactions usage considerations (such as runtime limit and oplog size limit), see also Production Considerations.
Without isolating the multi-document write operations, MongoDB exhibits the following behavior:
- Non-point-in-time read operations. Suppose a read operation begins at time t