[DOCS-11696] Docs for SERVER-34195: Support speculative readConcern behavior in transactions Created: 11/May/18  Updated: 29/Oct/23  Resolved: 04/Jun/18

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

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

Issue Links:
Documented
documents SERVER-34195 Support speculative readConcern behav... Closed
Participants:
Days since reply: 5 years, 36 weeks, 2 days ago
Epic Link: DOCS: 4.0 Server

 Description   

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.



 Comments   
Comment by Githook User [ 04/Jun/18 ]

Author:

{'username': 'kay-kim', 'name': 'kay', 'email': 'kay.kim@10gen.com'}

Message: DOCS-11599,DOCS-11696, DOCS-11750, DOCS-11658, DOCS-11619: txn retry, timelimit, speculative, write concern, informational ops
Branch: master
https://github.com/mongodb/docs/commit/5ae9b807789577b7ca926f689baa013061abc34c

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