[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:
Depends
depends on SERVER-36640 Add way for TransactionCoordinator to... Closed
depends on SERVER-38028 Participant with prepared transaction... Closed
Documented
is documented by DOCS-13283 Investigate changes in SERVER-37364: ... Closed
Duplicate
duplicates SERVER-37882 Switch the distributed transaction co... Closed
Related
related to DOCS-13288 Document that sharded transactions al... Closed
related to SERVER-47890 Unblacklist report_post_batch_resume_... Closed
related to SERVER-49423 Do not set coordinateCommitReturnImme... Closed
related to SERVER-52988 Unblacklist remaining test cases in t... Closed
related to SERVER-63971 Change server parameter to default to... Closed
related to SERVER-64515 Remove claims of prepare behavior fro... Open
related to SERVER-47130 Reduce w:majority commits from 4 to 2... Backlog
is related to SERVER-47993 Make coordinateCommitTransaction retu... Closed
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 (SERVER-38028), the coordinator can return to the client as soon as the commit decision is persisted (with the user's requested writeConcern, including journaling preference).

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 SERVER-47993 to change this as follow-on work.

Comment by Tess Avitabile (Inactive) [ 06/May/20 ]

Did you end up testing that we respect the user's writeConcern here?

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.

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: SERVER-37364 Coordinator should return the decision to the client as soon as the decision is durable
Branch: master
https://github.com/mongodb/mongo/commit/607f486bbb0211f1769b8bd2200b3cdaaaafe775

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: SERVER-37364 Temporarily disable coordinator returning decision as soon as decision is durable

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.
Branch: master
https://github.com/mongodb/mongo/commit/675c01a6f151c892fe683fc6ff05496b3bed10bf

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.

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