-
Type: Bug
-
Resolution: Done
-
Priority: Trivial - P5
-
Affects Version/s: None
-
Component/s: manual
-
Labels:None
The description of how locking works with oplog doesn't seem correct to me. This is on the concurrency FAQ page: http://docs.mongodb.org/manual/faq/concurrency/
In particular:
The mongod must lock both databases at the same time keep both data consistent and ensure that write operations, even with replication, are “all-or-nothing” operations.
My understanding is that the write is first done to the user DB, holding the lock for that DB, and then it is done to the oplog, holding the lock for the local DB. The locks happen as part of the same operation, but they are done serially. If the locks were in fact held at the same time, DB level locking would be of no real use in replica sets. The fact that they are done in serial and that writes to the oplog are extremely fast (capped collection, no index, almost always in memory) means that DB level locking does increase concurrency even in replica sets.
It is journaling and the fact that the user datafile writes and corresponding oplog writes are guaranteed to be part of the same journal batch that provides the all-or-nothing property (at least for a single node).
My above explanation should be checked with engineering and obviously includes a lot of detail that would not need to be part of a doc change.