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

An OpCtx's UncommittedCollections are retained after transaction resource stashing.

    • Fully Compatible
    • Sharding 2020-10-19

      When a command inside a running transaction returns a response, its (uncommitted) state is stashed into some map on session's in a structure called TxnResources. This stash includes things like locks, the current storage engine transaction and any collections the transaction has created.

      Stashing the uncommitted collections will create a new shared pointer for the TxnResources to hold onto.

      Unstashing the uncommitted collections asserts that the OperationContext does not know of any existing uncommitted collections.

      The stash -> unstash works so long as an operation context is destroyed after each "statement". This is the typical case as each new request over the wire creates a new operation context. However, internal code can send commands directly into the local system. This entry point executes all of the transaction related stashing logic, but also allows for the caller to provide the same operation context for each statement.

      The latter case can run into the above assertion when the transaction attempts (explicitly, or implicitly) to create a collection. This ticket is to make the stashing logic appropriately clean up the UncommittedCollections associated with an OpCtx.

      Original Description
      Assumptions exist for creating collections in replica set transactions that are outside of the scope of completion for Resharding's Milestone 1. In order to avoid spending too much time trying to debug collection creation in transactions, collection creation at the beginning of a resharding operation must be done outside of a transaction.

      Right now, this includes creating the config.reshardingOperations collection before attempting to insert to that collection here.

      Whoever works on this ticket must also find other places where collections are being written to in transactions as part of resharding, and assess whether it's possible that an operation leads to implicit collection creation. If so, the resharding collection must be optimistically outside of a transaction.

      For questions about how to implement this, and for code review, refer to Dan Gottlieb.

        1. invariant.diff
          10 kB
          Blake Oler

            Assignee:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Reporter:
            blake.oler@mongodb.com Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: