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

Use the Client mutex or the SessionCatalog mutex for concurrency control of the TransactionParticipant

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.9
    • Affects Version/s: None
    • Component/s: Internal Code
    • Labels:
      None
    • Fully Compatible
    • Sharding 2019-01-14, Sharding 2019-01-28, Sharding 2019-02-11, Sharding 2019-02-25
    • 0

      This ticket is for implementing the TransactionParticipant concurrency control change to look like this:

      • Changing the state of the TP requires the session to be checked out and the client mutex
      • Observing the state of the TP can be done in on two occasions:
        • Without any locks, if the session is checked out by the reader thread
        • With the session catalog mutex + if currently checked-out by another thread, using the client mutex of that thread.

      This rule can also be expressed as: When the Session holding the TransactionParticipant is checked-out, use the OperationContext concurrency rules (i.e., the Client mutex); When it is not checked-out only use the SessionCatalog’s mutex.

      Prepare transaction in this case becomes:

      • Check-out session
      • Take client mutex and check for interruption
      • Set the state of the TP to “prepared”

      Session invalidation and killAllExpiredTranasctions becomes:

      • In scanSessions, under the session catalog mutex, if session is checked-out currently, take the client mutex, otherwise don’t lock anything else
      • Check if the state is “prepared” and if so, skip this session
      • Check-out for kill any sessions, which weren’t skipped and call abortTransaction on them which must not be allowed to fail

      Session invalidation on stepDown and shutDown becomes:

      • In scanSessions, under the session catalog mutex, if session is checked-out currently, take the client mutex, otherwise don’t lock anything else
      • Unconditionally interrupt any operation contexts using this session
      • Check-out for kill all sessions and unconditionally force them to free their resources, which must not be allowed to fail

      All TP methods, which require the session to be checked-out will be changed to not accept OperationContext anymore, but to take it from the parent Session object and all methods which expose observable state will be changed to either acquire the client mutex or to accept a WithLock to indicate that they should be run under the client mutex.
      In order to reduce the confusion, there will only be two abort-related methods left on the TP:
      abortTransaction - used for the regular abort path, direct write to the config.transactions and for killAllExpiredTransactions. Executes the entire abort sequence, updates metrics.
      releaseTransactionResources - used for stepDown and shutDown. Releases the transaction’s resources unconditionally and makes the TP look as if it was just created

            Assignee:
            schwerin@mongodb.com Andy Schwerin
            Reporter:
            kaloian.manassiev@mongodb.com Kaloian Manassiev
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: