Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-2021

Locking of user DB and Local DB is not at same time

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Trivial - P5
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 01112017-cleanup
    • Component/s: manual
    • Labels:
      None
    • Last comment by Customer:
      true

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            sam.kleinman Sam Kleinman (Inactive)
            Reporter:
            thomas.boyd Thomas Boyd
            Participants:
            Last commenter:
            Jonathan Dahl Jonathan Dahl
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Days since reply:
              8 years, 17 weeks, 5 days ago
              Date of 1st Reply: