[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. |