FAQ: Concurrency

Changed in version 3.0.

MongoDB allows multiple clients to read and write the same data.In order to ensure consistency, it uses locking and otherconcurrency control measures to prevent multiple clientsfrom modifying the same piece of data simultaneously.Together, these mechanisms guarantee that all writes to a singledocument occur either in full or not at all and that clients neversee an inconsistent view of the data.

What type of locking does MongoDB use?

MongoDB uses multi-granularity locking [1] that allowsoperations to lock at the global, database or collection level, andallows for individual storage engines to implement their ownconcurrency control below the collection level (e.g., at thedocument-level in WiredTiger).

MongoDB uses reader-writer locks that allow concurrent readersshared access to a resource, such as a database or collection.

In addition to a shared (S) locking mode for reads and an exclusive(X) locking mode for write operations, intent shared (IS) and intentexclusive (IX) modes indicate an intent to read or write a resourceusing a finer granularity lock. When locking at a certain granularity,all higher levels are locked using an intent lock.

For example, when locking a collection for writing (using mode X),both the corresponding database lock and the global lock must belocked in intent exclusive (IX) mode. A single database cansimultaneously be locked in IS and IX mode, but an exclusive (X)lock cannot coexist with any other modes, and a shared (S) lock canonly coexists with intent shared (IS) locks.

Locks are fair, with reads and writes being queued in order. However,to optimize throughput, when one request is granted, all othercompatible requests will be granted at the same time, potentiallyreleasing them before a conflicting request. For example, considera case in which an X lock was just released, and in which theconflict queue contains the following items:

IS → IS → X → X → S → IS

In strict first-in, first-out (FIFO) ordering, only the first twoIS modes would be granted. Instead MongoDB will actually grant allIS and S modes, and once they all drain, it will grant X, even ifnew IS or S requests have been queued in the meantime. As a grantwill always move all other requests ahead in the queue, no starvationof any request is possible.

In db.serverStatus() and db.currentOp() output, thelock modes are represented as follows:

How granular are locks in MongoDB?

Changed in version 3.0.

Beginning with version 3.0, MongoDB ships with the WiredTiger storage engine.

For most read and write operations, WiredTiger uses optimisticconcurrency control. WiredTiger uses only intent locks at the global,database and collection levels. When the storage engine detectsconflicts between two operations, one will incur a write conflictcausing MongoDB to transparently retry that operation.

Some global operations, typically short lived operations involvingmultiple databases, still require a global “instance-wide” lock.Some other operations, such as dropping a collection, still requirean exclusive database lock.

How do I see the status of locks on my mongod instances?

For reporting on lock utilization information on locks, use any of thefollowing methods:

• db.serverStatus(),
• db.currentOp(),
• mongotop,
• mongostat, and/or
• the MongoDB Cloud Manager orOps Manager, an on-premise solution available inMongoDB Enterprise Advanced

Specifically, the locks document in the output ofserverStatus, or the locks fieldin the current operation reportingprovides insight into the type of locks and amount of lockcontention in your mongod instance.

In db.serverStatus() and db.currentOp() output, thelock modes are represented as follows:

To terminate an operation, use db.killOp().

Does a read or write operation ever yield the lock?

In some situations, read and write operations can yield their locks.

Long running read and write operations, such as queries, updates,and deletes, yield under many conditions. MongoDB operations canalso yield locks between individual document modifications in writeoperations that affect multiple documents likeupdate() with the multi parameter.

For storage engines supporting document level concurrencycontrol, such as WiredTiger, yielding is notnecessary when accessing storage as the intent locks, held at the global, database and collection level, do not blockother readers and writers. However, operations will periodically yield,such as:

• to avoid long-lived storage transactions because these canpotentially require holding a large amount of data in memory;
• to serve as interruption points so that you can kill long runningoperations;
• to allow operations that require exclusive access to a collectionsuch as index/collection drops and creations.

What locks are taken by some common client operations?

The following table lists some operations and the types of locks theyuse for document level locking storage engines:

Which administrative commands lock the database?

Certain administrative commands can exclusively lock the database forextended periods of time. In some deployments, for large databases,you may consider taking the mongod instance offline so thatclients are not affected. For example, if a mongod is partof a replica set, take the mongod offline and letother members of the set service load while maintenance is in progress.

The following administrative operations require an exclusivelock at the database level for extended periods:

The following administrative operations lock the database but only holdthe lock for a very short time:

See also

Does a MongoDB operation ever lock more than one database?

Which administrative commands lock a collection?

Changed in version 4.2.

The following administrative operations require an exclusive lock atthe collection level:

Prior to MongoDB 4.2, these operations took an exclusive lock on thedatabase, blocking all operations on the database and its collectionsuntil the operation completed.

Does a MongoDB operation ever lock more than one database?

The following MongoDB operations take a global exclusive lock:

• db.copyDatabase() obtains a global exclusive(W) lock and will block other operations until it finishes.
• Starting in MongoDB 4.0, db.collection.reIndex() takes aglobal exclusive (W) lock and will blockother operations until it finishes.
• User authentication requires a readlock on the admin database for deployments using 2.6 usercredentials. For deployments usingthe 2.4 schema for user credentials, authentication locks theadmin database as well as the database the user is accessing.
• All writes to a replica set’s primary lock both the databasereceiving the writes and then the local database for a shorttime. The lock for the local database allows themongod to write to the primary’s oplog andaccounts for a small portion of the total time of the operation.
• Replica set member state transitions take global exlusive lock.

How does sharding affect concurrency?

Sharding improves concurrency by distributingcollections over multiple mongod instances, allowing shardservers (i.e. mongos processes) to perform any number ofoperations concurrently to the various downstream mongodinstances.

In a sharded cluster, locks apply to each individual shard, not tothe whole cluster; i.e. each mongod instance isindependent of the others in the sharded cluster and uses its ownlocks. The operations on onemongod instance do not block the operations on any others.

How does concurrency affect a replica set primary?

With replica sets, when MongoDB writes to a collection on theprimary, MongoDB also writes to the primary’s oplog,which is a special collection in the local database. Therefore,MongoDB must lock both the collection’s database and the localdatabase. The mongod must lock both databases at the sametime to keep the database consistent and ensure that write operations,even with replication, are “all-or-nothing” operations.

When writing to a replica set, the lock’s scopeapplies to the primary.

How does concurrency affect secondaries?

In replication, MongoDB does not apply writes serially tosecondaries. Secondaries collect oplog entries inbatches and then apply those batches in parallel. Secondaries do notallow reads while applying the write operations, and apply writeoperations in the order that they appear in the oplog.

Does MongoDB support transactions?

Because a single document can contain related data that would otherwisebe modeled across separate parent-child tables in a relational schema,MongoDB’s atomic single-document operations already provide transactionsemantics that meet the data integrity needs of the majority ofapplications. One or more fields may be written in a single operation,including updates to multiple sub-documents and elements of an array.The guarantees provided by MongoDB ensure complete isolation as adocument is updated; any errors cause the operation to roll back sothat clients receive a consistent view of the document.

However, for situations that require atomicity of reads and writesto multiple documents (in a single or multiple collections), MongoDBsupports multi-document transactions:

• In version 4.0, MongoDB supports multi-document transactions onreplica sets.

• In version 4.2, MongoDB introduces distributed transactions,which adds support for multi-document transactions on shardedclusters and incorporates the existing support formulti-document transactions on replica sets.

For details regarding transactions in MongoDB, see theTransactions page.

Important

In most cases, multi-document transaction incurs a greaterperformance cost over single document writes, and theavailability of multi-document transactions should not be areplacement for effective schema design. For many scenarios, thedenormalized data model (embedded documents and arrays) will continue to be optimal for yourdata and use cases. That is, for many scenarios, modeling your dataappropriately will minimize the need for multi-documenttransactions.

For additional transactions usage considerations(such as runtime limit and oplog size limit), see alsoProduction Considerations.

What isolation guarantees does MongoDB provide?

Depending on the read concern, clients can see the results of writesbefore the writes are durable. To control whether the data readmay be rolled back or not, clients can use the readConcern option.

For information, see:

• Read Isolation, Consistency, and Recency
• Atomicity and Transactions
• Read Concern