[SERVER-63597] Implicit transaction aborts should still wait for write concern for non-transient errors Created: 11/Feb/22  Updated: 02/Mar/22  Resolved: 01/Mar/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Moustafa Maher
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Sprint: Repl 2022-03-07
Participants:

 Description   

SERVER-54534 made it so that implicit transaction aborts don't wait for write concern (FWIW, we never waited for write concerns for explicit abortTransaction command). This means that if a transaction is implicitly aborted (e.g. due to WriteConflict / DuplicateKey errors), it will not wait for the data the transaction observed to be majority committed before returning.

For implicit transaction aborts, we will want to wait for write concern for non-transient transaction errors like DuplicateKey so that a subsequent majority read (outside of transaction) is guaranteed to the conflicting write (in the absence of primary failovers).

For transient errors, we don't have to wait for write concern as the transaction is retryable. But we may still want to wait for write conflict errors so that transactions with snapshot readConcern are guaranteed to read from an updated all_durable on retries.

So this effectively reverts SERVER-54534.



 Comments   
Comment by Moustafa Maher [ 02/Mar/22 ]

huayu.ouyang yes. 

Comment by Huayu Ouyang [ 02/Mar/22 ]

m.maher So does this mean that REP-204 needs to be done?

Generated at Thu Feb 08 05:58:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.