[SERVER-37175] POC: Constant transaction number per participant Created: 17/Sep/18 Updated: 25/Jul/19 Resolved: 25/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | Matthew Russotto |
| Resolution: | Done | Votes: | 0 |
| Labels: | prepare_optional | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Repl 2019-06-17, Repl 2019-07-01, Repl 2019-07-15, Repl 2019-07-29 | ||||||||
| Participants: | |||||||||
| Description |
|
There is a one-to-one mapping between the txnNumber and a transaction participant / retryable write (no transaction). We should make a participant only know of its constant transaction number. Bumping txnNumber will try to abort the current participant, which throws an exception if it can't, and start a new one. As a result, participant only needs to check its state (aborted or not) and should never know of the change of the transaction number. |
| Comments |
| Comment by Matthew Russotto [ 25/Jul/19 ] |
|
We did the POC. This looks like a viable way to proceed, but both because it won't help us in the short run and because we may be doing refactors of the TransactionParticipant for other projects (which it would make sense to do this as part of, or at least to consider those designs in the design for a final version of this), we're not doing this refactor right now. |
| Comment by Siyuan Zhou [ 17/May/19 ] |
|
One problem we hope this can solve is that we have different ways to clean the state of transaction participant. |