[SERVER-37514] Snapshot readConcern without atClusterTime should always be speculative Created: 08/Oct/18  Updated: 29/Oct/23  Resolved: 11/Oct/18

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

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

Issue Links:
Backports
Depends
Related
is related to SERVER-37516 Providing readConcern on second trans... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Sprint: Repl 2018-10-22
Participants:
Linked BF Score: 0

 Description   

Read concern level snapshot executes speculatively if the command is run as part of a transaction and atClusterTime is not provided. However, we allow read concern level snapshot if the command is run as part of an active or killed transaction. This means that if the transaction has been killed, we will wait for read concern with non-speculative behavior. This behavior is not supported. When atClusterTime is not specified, we always expect transactions to execute speculatively. One issue that could arise is that on mongods with enableMajorityReadConcern:"false", we will attempt to obtain a majority committed snapshot. This always returns a non-ok status, so we will loop forever waiting for majority reads to become available.

Note that we expect this issue to be rare outside of tests. It only occurs when a readConcern is specified on the operation, which a driver would only do if it is the first operation of the transaction. For a transaction to be killed on the first operation in a transaction, before the waitForReadConcern, there would need to be a concurrent killSessions. This issue is more likely to occur if there is a readConcern on a subsequent transaction operation, which a driver would not do. In that case, the transaction could have been aborted earlier for any reason. We wait for read concern here before we unstash resources here, which throws if a read concern is provided and the transaction is in progress, so we do not catch the problem until we have already waited.



 Comments   
Comment by Githook User [ 11/Oct/18 ]

Author:

{'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}

Message: SERVER-37514 Snapshot readConcern without atClusterTime should always be speculative

(cherry picked from commit cc99b89e8c2ecbae3b4ae006f0a97927fe6040ce)
Branch: v4.0
https://github.com/mongodb/mongo/commit/9059ddd51b864b35049f128eabaf8c89bd39d98e

Comment by Githook User [ 11/Oct/18 ]

Author:

{'name': 'Tess Avitabile', 'email': 'tess.avitabile@mongodb.com', 'username': 'tessavitabile'}

Message: SERVER-37514 Snapshot readConcern without atClusterTime should always be speculative
Branch: master
https://github.com/mongodb/mongo/commit/cc99b89e8c2ecbae3b4ae006f0a97927fe6040ce

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