-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Labels:None
-
Fully Compatible
-
Repl 2018-04-23, Repl 2018-05-07
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.
- is documented by
-
DOCS-11696 Docs for SERVER-34195: Support speculative readConcern behavior in transactions
- Closed
- is duplicated by
-
SERVER-34532 Spurious WriteConflict error with multi-statement transactions
- Closed
- is related to
-
SERVER-34038 Make sure that commitTransaction waits for writeConcern after a read-only transaction
- Closed