Description:

No documentation summary in engineering ticket

if your transaction commits (with writeConcern w:majority), then you can be
confident any data you read in your transaction was committed.

Scope of changes:

• read-concern – done through earlier commit
• read-concern-snapshot – done through earlier commit
• transactions

  Impact to other docs outside of this product:

none

MVP:

Resources:

Engineering Ticket Description:

Rather than open at an already-majority-committed snapshot, transactions can open at the last-applied snapshot, allowing back-to-back transactions with w:1 write concern and transactions started after w:1 writes to read the prior writes without stalling for replication. In the event that replication fails, the transaction will abort. Users interested in detecting this failure should commit transactions with w:majority write concern.

This optimization reduces the write conflict rate for transactions operating on frequently written documents. In exchange, applications that read data during transaction execution and use that data to make decisions outside the database must wait for their transactions to commit with w:majority write concern in order to be certain that the observed data meets the user-requested read concern level. Put more simply, if you don't know that your transaction successfully committed, you should not expect the data you read to be consistent.