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

[txnRetryCounter] Use txnRetryCounter on router to retry on some transient errors in a client transaction

    • Type: Icon: Task Task
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Cluster Scalability
    • Sharding 2022-07-25, Sharding 2022-08-08, Sharding 2022-08-22, Sharding 2022-09-05, Sharding 2022-09-19, Sharding 2022-10-03, Sharding 2022-10-17, Sharding NYC 2022-10-31

      Currently, if any shard participant in a sharded transaction returns a transient error, the error is returned to the client, which will retry after incrementing the transaction number. With the introduction of txnRetryCounter in SERVER-58752, the router running the transaction can instead catch transient errors in some situations and retry with a higher txnRetryCounter without involving the client, improving performance.

       

      In this ticket, mongos will retry on all transient transaction errors encountered during the first stmt id, regardless of the number of participants involved. The mongos will start a new transaction with an incremented txnRetryCounter value, and the mongod will consider this request as a new transaction.

       

      Note, we can revert this commit to readd support for the txnRetryCounter and that there are some tests that will need to be re-enabled, see comments below. 

            Assignee:
            backlog-server-cluster-scalability [DO NOT USE] Backlog - Cluster Scalability
            Reporter:
            jack.mulrow@mongodb.com Jack Mulrow
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: