[SERVER-77589] coordinateCommitTransaction shouldn't always wait for last system opTime Created: 30/May/23  Updated: 05/Feb/24

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jack Mulrow Assignee: Kshitij Gupta
Resolution: Unresolved Votes: 0
Labels: sharding-nyc-subteam2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding NYC
Sprint: Sharding NYC 2023-06-12, Sharding NYC 2023-06-26, Sharding NYC 2023-07-10, Sharding NYC 2023-07-24, Sharding NYC 2023-08-07, Sharding NYC 2023-08-21, Sharding NYC 2023-09-04, Sharding NYC 2023-09-18, Sharding NYC 2023-10-02, Sharding NYC 2023-10-16, Sharding NYC 2023-10-30, Cluster Scalability 2023-11-13, Cluster Scalability 2023-11-27, Cluster Scalability 2023-12-11, Cluster Scalability 2023-12-25, Cluster Scalability 2024-1-8, Cluster Scalability 2024-1-22, Cluster Scalability 2024-2-5, Cluster Scalability 2024-2-19
Participants:
Story Points: 3

 Description   

Currently, the coordinateCommitTransaction command sets its client opTime to the system latest to guarantee it waits for a time at least as great as the time the decision was written at. When true, the coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter lets coordinateCommitTransaction return as soon as the decision is written locally, so this allows respecting a user's write concern weaker than majority. As of SERVER-63971, that parameter is false by default, so now coordinateCommitTransaction only ends after the coordinator has received decision acknowledgements from all shards. The decision is sent with majority write concern, so coordinateCommitTransaction has effectively already waited for majority write concern, but will still set its client opTime forward, and likely end up waiting for majority write concern again.

This means in the normal case, a two phase commit transaction will wait for 5 sequential majority replications:
1. Coordinator writing the participant list
2. Participants applying prepareTransaction
3. Coordinator writing the decision
4. Participants applying the decision
5. Coordinator waiting for system last opTime before returning from coordinateCommitTransaction

The final wait is after the transaction has majority committed on all participants, so instead coordinateCommitTransaction should return immediately (as long as the user's write concern isn't stronger than majority). A possible fix is for the transaction coordinator to return an opTime for coordinateCommitTransaction to wait on, instead of having the command use the last system opTime.


Generated at Thu Feb 08 06:36:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.