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

Revisit design of TransactionCoordinator with goal to bound the number of threads it spawns

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Replication

      TransactionCoordinator runs tasks on the fixed executor and the fixed executor has the behavior where it'll spawn a new thread to execute the task if an idle thread isn't already available. This behavior is important for the liveness of the system because it prevents tasks which would unblock other operations from being delayed indefinitely. However the truly urgent portion of the TransactionCoordinator starts from when the prepareTransaction command is issued to the participant shards through the last participant shard having responded to the commitTransaction xor abortTransaction command. The other portions of the TransactionCoordinator are not time-sensitive because they don't acutely impact the success of concurrent read and write operations.

      george.wangensteen@mongodb.com suggests taking a further step back from the issue of spawning too many threads and modeling the TransactionCoordinator as a series of queues whether work passes between these queues and there are different thread pools and policies for processing the work in these queues.

            Assignee:
            Unassigned Unassigned
            Reporter:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Votes:
            0 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: