Read Isolation, Consistency, and Recency¶

On this page

Isolation Guarantees
Consistency Guarantees
Recency

Isolation Guarantees¶

Read Uncommitted¶

In MongoDB, clients can see the results of writes before the writes are durable:

Regardless of write concern, other clients using "local" (i.e. the default) readConcern can see the result of a write operation before the write operation is acknowledged to the issuing client.
Clients using "local" (i.e. the default) readConcern can read data which may be subsequently rolled back.

Read uncommitted is the default isolation level and applies to mongod standalone instances as well as to replica sets and sharded clusters.

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 reader will never see the document with only some of the fields updated.

With a single mongod instance, a set of read and write operations to a single document is serializable. With replica sets, only in the absence of a rollback, is a set of read and write operations to a single document serializable.

However, although the readers may not see a partially updated document, read uncommitted means that concurrent readers may still see the updated document before the changes are durable.

Read Uncommitted And Multiple Document Write¶

When a single write operation modifies multiple documents, the modification of each document is atomic, but the operation as a whole is not atomic and other operations may interleave. However, you can isolate a single write operation that affects multiple documents using the $isolated operator.

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₁ and starts reading documents. A write operation then commits an update to one of the documents at some later time t₂. The reader may see the updated version of the document, and therefore does not see a point-in-time snapshot of the data.
Non-serializable operations. Suppose a read operation reads a document d₁ at time t₁ and a write operation updates d₁ at some later time t₃. This introduces a read-write dependency such that, if the operations were to be serialized, the read operation must precede the write operation. But also suppose that the write operation updates document d₂ at time t₂ and the read operation subsequently reads d₂ at some later time t₄. This introduces a write-read dependency which would instead require the read operation to come after the write operation in a serializable schedule. There is a dependency cycle which makes serializability impossible.
Dropped results for MMAPv1. For MMAPv1, reads may miss matching documents that are updated or deleted during the course of the read operation. However, data that has not been modified during the operation will always be visible.

Using the $isolated operator, a write operation that affects multiple documents can prevent other processes from interleaving once the write operation modifies the first document. This ensures that no client sees the changes until the write operation completes or errors out.

$isolated does not work with sharded clusters.

An isolated write operation does not provide “all-or-nothing” atomicity. That is, an error during the write operation does not roll back all its changes that preceded the error.

Note

$isolated operator causes write operations to acquire an exclusive lock on the collection, even for document-level locking storage engines such as WiredTiger. That is, $isolated operator will make WiredTiger single-threaded for the duration of the operation.

Cursor Snapshot¶

MongoDB cursors can return the same document more than once in some situations. As a cursor returns documents other operations may interleave with the query. If some of these operations are updates that cause the document to move (in the case of MMAPv1, caused by document growth) or that change the indexed field on the index used by the query; then the cursor will return the same document more than once.

In very specific cases, you can isolate the cursor from returning the same document more than once by using the cursor.snapshot() method. For more information, see How do I isolate cursors from intervening write operations?.

Consistency Guarantees¶

Monotonic Reads¶

MongoDB provides monotonic reads from a standalone mongod instance. Suppose an application performs a sequence of operations that consists of a read operation R₁ followed later in the sequence by another read operation R₂. If the application performs the sequence on a standalone mongod instance, the later read R₂ never returns results that reflect an earlier state than that returned from R₁; i.e. R₂ returns data that is monotonically increasing in recency from R₁.

Changed in version 3.2: For replica sets and sharded clusters, MongoDB provides monotonic reads if read operations specify Read Concern "majority" and read preference primary.

In previous versions, MongoDB cannot make monotonic read guarantees from replica sets and sharded clusters.

Monotonic Writes¶

MongoDB provides monotonic write guarantees for standalone mongod instances, replica sets, and sharded clusters.

Suppose an application performs a sequence of operations that consists of a write operation W₁ followed later in the sequence by a write operation W₂. MongoDB guarantees that W₁ operation precedes W₂.

Recency¶

In MongoDB, in a replica set with one primary member [1],

With "local" readConcern, reads from the primary reflect the latest writes in absence of a failover;
With "majority" readConcern, read operations from the primary or the secondaries have eventual consistency.

[1] In some circumstances, two nodes in a replica set may transiently believe that they are the primary, but at most, one of them will be able to complete writes with { w: "majority" } write concern. The node that can complete { w: "majority" } writes is the current primary, and the other node is a former primary that has not yet recognized its demotion, typically due to a network partition. When this occurs, clients that connect to the former primary may observe stale data despite having requested read preference primary, and new writes to the former primary will eventually roll back.

← Bulk Write Operations MongoDB CRUD Tutorials →

Was this page helpful?

Yes No

Thank you for your feedback!

We're sorry! You can Report a Problem to help us improve this page.