[SERVER-37364] Coordinator should return the decision to the client as soon as the decision is durable Created: 27/Sep/18 Updated: 29/Oct/23 Resolved: 06/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | Cheahuychou Mao |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ShardedTxn:DistributedCommit, ShardedTxn:FutureOptimizations, pm-564, transaction-coordinator-management | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Sharding 2018-11-05, Sharding 2020-04-20, Sharding 2020-05-04, Sharding 2020-05-18 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Currently, the coordinator waits for all participants to ack the decision before returning the decision to the client. Once a participant with a prepared transaction blocks requests with a higher transaction number rather than return PreparedTransactionInProgress ( Note that if the user requested w:1 writeConcern, the decision may roll back after being reported to the client, but regardless all participants will apply the same decision. |
| Comments |
| Comment by Tess Avitabile (Inactive) [ 06/May/20 ] |
|
Awesome, thank you! |
| Comment by Esha Maharishi (Inactive) [ 06/May/20 ] |
|
tess.avitabile, ah, thanks, we forgot to test this. I also checked and right now the coordinator is actually only returning the decision once the decision is majority-committed. I filed |
| Comment by Tess Avitabile (Inactive) [ 06/May/20 ] |
|
Did you end up testing that we respect the user's writeConcern here?
Also, I'm really excited to see this ticket get pushed! |
| Comment by Githook User [ 06/May/20 ] |
|
Author: {'name': 'Cheahuychou Mao', 'email': 'cheahuychou.mao@mongodb.com', 'username': 'cheahuychou'}Message: |
| Comment by Mira Carey [ 27/Mar/20 ] |
|
Putting this in quick wins, assuming it's only a couple of days to revisit our earlier implementation. If this starts dragging out, we'll put this back on the backlog |
| Comment by Tess Avitabile (Inactive) [ 08/Nov/18 ] |
|
We should ensure that we respect the user writeConcern here. For example, if the user requested w:1, we should return as soon as the decision is persisted with w:1. |
| Comment by Githook User [ 07/Nov/18 ] |
|
Author: {'name': 'Esha Maharishi', 'email': 'esha.maharishi@mongodb.com', 'username': 'EshaMaharishi'}Message: Instead, the coordinator will wait for all acks before returning the decision. Re-enable when all tests have been updated to handle a decision being returned early, possibly by making a request with a higher transaction number block if it is received by a participant still in prepare for an earlier transaction. |
| Comment by Esha Maharishi (Inactive) [ 07/Nov/18 ] |
|
Re-opening because I am disabling making the coordinator return the decision as soon as the decision is durable. Some tests start a transaction with a higher transaction number immediately on hearing OK for committing the previous transaction, but if the new transaction's request arrives at a participant (which is still in prepare) before the participant hears the decision, the participant will fail the new request, which causes the tests to fail. |