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

Handle non-locking killCursors in transactions

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Querying
    • None
    • Query Execution

    Description

      In MongoDB 4.0, when theĀ killCursors command is issued as part of a transaction, it checks out the session and uses the same locker as the transaction. This is important because killCursors must take locks, so if it used a different locker, then it could block behind a DDL operation that is blocked behind the transaction, preventing the killCursors (and the transaction that it is part of) from making progress.

      When all cursors are globally managed, killCursors will no longer need to take locks. This means it no longer needs to use the same locker as the transaction. It also means that killCursors will trigger an invariant if it is the first operation in the transaction, sinceĀ we expect the locker to be non-empty when we release its WT ticket and stash transaction resources.

      We have a few options for how to address this. We could ban killCursors from being the first statement in a transaction. We could ban killCursors in transactions entirely (though this would require drivers changes). Or we could allow transactions to stash an empty locker.

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            tess.avitabile@mongodb.com Tess Avitabile (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: