[SERVER-77864] Make the use of the AlternativeClientRegion for replay protection implicit Created: 07/Jun/23 Updated: 26/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Enrico Golfieri | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | oldshardingemea, shardingemea-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Catalog and Routing
|
| Participants: | |
| Story Points: | 3 |
| Description |
|
In order to guarantee replay protection many command such as ShardsvrParticipantBlock will run within a This is ok since the only reason we use a retryable write is indeed to guarantee replay protection, which is a situation in which a DDL is retried by a node that is no longer the primary (this can happen because of a network partition). By storing session information in the oplog, any request coming with a txnNumber lower then the persisted one will result in an error, preventing the old primary to successfully commit. At the moment there is no better solution unless we re-think a way to guarantee replay protection without forcing those commands to run within a retryable write. The goal of the ticket is to simplify the readability of and re-usage of the boilerplate code that prevents the deadlock. We could do this by hiding the code in a RAII object helper class or by executing it from the entry point (this might require some design). |