[SERVER-41356] Always choose a write shard as the transaction two-phase commit coordinator Created: 29/May/19  Updated: 24/Jan/23  Resolved: 24/Jan/23

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

Type: Improvement Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Adi Zaimi
Resolution: Duplicate Votes: 0
Labels: ShardedTxn:FutureOptimizations, sharding-common-backlog, sharding-nyc-subteam3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-40783 For a transaction that requires two-p... Backlog
Assigned Teams:
Sharding NYC
Participants:

 Description   

Currently, the first participant is chosen as the two-phase commit coordinator. This means that if that participant ends up being read-only, the two-phase commit will not have the benefit of any of the participants being local.

This would only improve the tail latency of two-phase commit.

It is slightly complicated because in order to choose a write shard, the router has to first know whether the participant has done a write, which means the router cannot piggyback "coordinator: true" on the request to the participant.



 Comments   
Comment by Adi Zaimi [ 24/Jan/23 ]

Will be done as part of SERVER-40783.

Comment by Adi Zaimi [ 17/Jan/23 ]

Need to discuss with Max/Jack to clarify if this is any longer applicable. Today we presumably commit the txn in the shards that performed only a read as part of txn, and if that will remain so then this tkt is obsolete.
If we are planning to add back optimization that only write shards commit the txn, then we may need to put this tkt back in the backlog.

Generated at Thu Feb 08 04:57:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.