11.4.7 Does a MongoDB operation ever lock more than one database? 11.4.8 How does sharding affect concurrency? 11.4.9 How does concurrency affect a replica set primary? 11.4.10 How does concurrency affect secondaries? 11.4.11 What kind of concurrency does MongoDB provide for JavaScript opera- tions? MongoDB Documentation, Release 3.0.4 The following MongoDB operations lock multiple databases: Sharding improves concurrency by distributing collections over multiple mongod instances, allowing shard servers (i.e. mongos processes) to perform any number of operations concurrently to the various downstream mongod instances. Each mongod instance is independent of the others in the shard cluster and uses its own locks (page 758). The operations on one mongod instance do not block the operations on any others. In replication , when MongoDB writes to a collection on the primary , 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 local database. The mongod must lock both databases at the same time to keep the database consistent and ensure that write operations, even with replication, are “all-or-nothing” operations. In replication , MongoDB does not apply writes serially to secondaries . Secondaries collect oplog entries in batches and then apply those batches in parallel. Secondaries do not allow reads while applying the write operations, and apply write operations in the order that they appear in the oplog. MongoDB can apply several writes in parallel on replica set secondaries, in two phases: Changed in version 2.4: The V8 JavaScript engine added in 2.4 allows multiple JavaScript operations to run at the same time. Prior to 2.4, a single mongod could only run a single JavaScript operation at once. 761 11.4. FAQ: Concurrency 1. During the first prefer phase, under a read lock, the mongod ensures that all documents affected by the opera- tions are in memory. During this phase, other clients may execute queries against this member. 2. A thread pool using write locks applies all write operations in the batch as part of a coordinated write phase. • All writes to a replica set’s primary lock both the database receiving the writes and then the local database for a short time. The lock for the local database allows the mongod to write to the primary’s oplog and accounts for a small portion of the total time of the operation. • User authentication (page 320) requires a read lock on the admin database for deployments using 2.6 user credentials (page 416). For deployments using the 2.4 schema for user credentials, authentication locks the admin database as well as the database the user is accessing. • Journaling , which is an internal operation, locks all databases for short intervals. All databases share a single journal. • db.repairDatabase() obtains a global write lock and will block other operations until it finishes. • db.copyDatabase() must lock the entire mongod instance at once.