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

Transaction API shouldn't block on an uncancelable operation

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.3.0-rc0
    • Affects Version/s: 6.2.0-rc1, 6.3.0-rc0
    • Component/s: None
    • Labels:
      None
    • Fully Compatible
    • ALL
    • 35

      After callers of the synchronous internal transaction API are interrupted, the cancellation token of the transaction is canceled and the caller waits for the transaction to complete uninterruptibly to guarantee the callback provided to the API has completed and its referenced variables are still in scope. This relies on the assumption that cancelling the token for the transaction will soon complete the transaction.

      SERVER-70247 fixed an issue where cancelling the transaction API will prevent the API from best effort aborting its transaction, leading to wasted resources. The fix made the best effort abort always use an uncancelable cancellation token. The API still forces callers to wait for the best effort abort to complete before returning though, so if the abort hangs, the caller will hang as well.

      This can trigger a deadlock if the caller of the API holds a resource like a SessionCatalog session for a different session than the transaction uses (e.g. if the caller uses the transaction API from an AlternativeClientRegion) that can prevent a stepdown from completing which may block the abort command when it tries to take the RSTL before running.

      A possible fix is to refactor the API so it does not block the caller waiting for the best effort abort.

            Assignee:
            jack.mulrow@mongodb.com Jack Mulrow
            Reporter:
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: