Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-50018

lock order is reversed when updating config.transactions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Won't Fix
    • Affects Version/s: 3.6.18
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Operating System:
      ALL

      Description

      Operations that work on the config database would take the config db lock first and then the local db lock to write to the oplog. However, when updating config.transactions for retryable writes or transactions, the local lock is taken first and then followed by config. At first glance it may look like the logOp is taking the local lock in this scope, but there are certain cases where unlock can be deferred until WUOW is finished. And the oplog write during retryable write or transactions falls into this case. In summary, what appeared to be a sequence of [lock local, unlock local, lock config, unlock config] is in fact, [lock local, (defer unlock local), lock config, unlock config, (unlock local for real)].

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              backlog-server-sharding Backlog - Sharding Team
              Reporter:
              renctan Randolph Tan
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: