-
Type: Task
-
Resolution: Unresolved
-
Priority: 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.
- related to
-
SERVER-89931 StaleConfig error is not retried as a first statement in a txn with FLE sharded collections
- Closed