[SERVER-34238] Only call waitForReadConcern in the first statement of a multi-statement transaction Created: 30/Mar/18  Updated: 27/Oct/23  Resolved: 03/Apr/18

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

Type: Bug Priority: Major - P3
Reporter: James Wahlin Assignee: Tess Avitabile (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   


 Comments   
Comment by Tess Avitabile (Inactive) [ 03/Apr/18 ]

We already only call waitForReadConcern for the first statement in a transaction, since we do it before unstashing the readConcern for the transaction. Even if a later command in the transaction specifies a readConcern and we waitForReadConcern, we will not be in a WUOW while waiting (and we will reject the command during unstashing).

Comment by James Wahlin [ 03/Apr/18 ]

The problem originally reported by this ticket is longer an issue for snapshot reads as of this commit.

I suspect the referenced call to waitForReadConcern() may still be an issue for multi-statement transactions however. The call to waitForReadConcern() here makes use of the OperationContext ReadConcernArgs decoration prior to us unstashing the transaction's ReadConcernArgs object. As only the first statement in a multi-statement transaction provides readConcern information, this will be wrong for every statement beyond the first. I suspect we should only call waitForReadConcern() when running the first statement of a multi-statement transaction.

Repurposing ticket and sending to the Repl team to triage.

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