[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: |
|
||||||||
| 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. |