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

• per Server ticket comment need to update https://docs.mongodb.com/manual/reference/read-concern/#read-concern-levels?

Impact to Other Docs

MVP (Work and Date)

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