[SERVER-37516] Providing readConcern on second transaction statement can corrupt transaction Created: 08/Oct/18  Updated: 09/Nov/18  Resolved: 09/Nov/18

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

Type: Bug Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Siyuan Zhou
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-37179 Wait for specified write concern when... Closed
Related
related to SERVER-37514 Snapshot readConcern without atCluste... Closed
is related to SERVER-37179 Wait for specified write concern when... Closed
Operating System: ALL
Sprint: Repl 2018-10-22, Repl 2018-11-05, Repl 2018-11-19
Participants:

 Description   

We do not allow read concern on transaction statements after the first one. However, we do not check for this until unstashTransactionResources(), which occurs after we wait for read concern. This is problematic, since providing a read concern a subsequent statement does not abort the transaction, but waiting for read concern has side effects, such as setting the read timestamp of the transaction, which is used for the writeConcern wait on commitTransaction. This means you could end up with a corrupted transaction.

This is not a major issue, since drivers and mongos will not send readConcern on subsequent transaction statements.



 Comments   
Comment by Tess Avitabile (Inactive) [ 09/Nov/18 ]

Yes, I think the bug went away with your change.

Comment by Siyuan Zhou [ 09/Nov/18 ]

With pushing down starting transaction to before command execution in SERVER-37179, waiting for read concern purely depends on users' input. The side-effect of setting read timestamp is also pushed down to unstashTransaction, so waiting for read concern has no impact on the transaction state. Besides, snapshot read concern is only allowed when startTransaction: true is specified in SERVER-37179.

If a user specifies the read concern and startTransaction for the second command, we'll still find it later when starting the transaction as described above. However, it shouldn't have any side-effect and should be rare since drivers and mongos won't do that.

tess.avitabile, do you think your concerns in the description are addressed by SERVER-37179? If so, I'll go ahead and close this as a dup.

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