Committing a transaction which was started with a killCursors command can fail

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 4.1.6
    • Affects Version/s: None
    • Component/s: Querying
    • None
    • Fully Compatible
    • ALL
    • Repl 2018-11-19
    • 4
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      AsyncResultsMerger::blockingKill() sends a killCursors command to each of its remotes. However, it discards the callback handle for the request, so blockingKill() can return before the killCursors command reaches the remote. This means that if the client issues a killCursors command, and then a commitTransaction command, a shard can receive the commitTransaction before the killCursors. This is problematic in combination with transactions. Consider the following sequence of events:

      • User starts transaction 0 with killCursors sent to mongos.
      • User receives ok response.
      • User sends commitTransaction for transaction 0 to mongos.
      • mongod receives commitTransaction, which fails since transaction 0 does not yet exist.
      • mongod receives killCursors, which starts transaction 0.

      Now the mongod is stuck with transaction 0 open.

            Assignee:
            Samyukta Lanka
            Reporter:
            Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: