[DOCS-12871] Investigate changes in SERVER-39672: ReadConcern level in multi-statement transactions defaults to "snapshot" Created: 10/Jul/19  Updated: 13/Nov/23  Resolved: 23/Jul/19

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: 4.1.10, 4.0.10, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Kay Kim (Inactive)
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-39672 ReadConcern level in multi-statement ... Closed
Participants:
Days since reply: 4 years, 29 weeks, 1 day ago
Epic Link: DOCS: 4.2 Server/Tools

 Description   

Description

Change Description:

A transaction started with no explicit readConcern used to default to readConcern level "snapshot", now it defaults to "local".

SERVER ticket description:

If a user starts a transaction with no readConcern level (the default), the transaction reads from the all-committed snapshot instead of at the last applied timestamp. The expected behavior is if there is no readConcern level it behaves the same as an explicit readConcern level "local" and reads from the last applied timestamp.

Transactions with an explicit readConcern level "local" behave correctly, the bug affects the default common case, with no explicit level.

Details: In _extractReadConcern in service_entry_point common, if we're starting a multi-statement transaction, we save the user's readConcern level as ReadConcernArgs::_originalLevel, and replace ReadConcernArgs::_level with kSnapshot. Later, we determine whether to read from a snapshot by calling ReadConcernArgs::getOriginalLevel(). judah.schvimer says the intention of this is to make readConcern::getLevel() return kSnapshot in all multi-statement transactions. He says "We upconvert all readconcerns to snapshot for ease of coding, but we use the original read concern level when calling _setSpeculativeTransactionOpTime". (I, Jesse, don't know how this eases coding yet.)

However, getOriginalLevel() doesn't fulfill this intention. If the client provides no readConcern, then ReadConcernArgs::_originalLevel is boost::none. Then getOriginalLevel() does:

    return _originalLevel.value_or(getLevel());

... which is the upconverted level, "snapshot"!

Scope of changes

  • We already mention on txn pages: {{By default, client-level read concern is "local" for reads against the primary. }}

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Kay Kim (Inactive) [ 23/Jul/19 ]

Mention of the server issue is included in https://docs.mongodb.com/manual/release-notes/4.0/#may-31-2019

Comment by A. Jesse Jiryu Davis [ 11/Jul/19 ]

Just to clarify:

"local" is the right behavior
"snapshot" is the wrong behavior, SERVER-39672 is a bug because the server was choosing the wrong behavior: "snapshot"
so we changed it from "snapshot" (wrong) to local (right), in 4.0.10

the docs were always correct, but the server didn't match the docs until 4.0.10

maybe the docs should mention that the server used the wrong default ("snapshot") until 4.0.10

and stripe wants the documentation, which always claimed we behaved correctly ("local") to note that this wasn't always true (used to be "snapshot")

Generated at Thu Feb 08 08:06:20 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.