Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-11696

Docs for SERVER-34195: Support speculative readConcern behavior in transactions

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None


      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:




      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.

            kay.kim@mongodb.com Kay Kim (Inactive)
            kay.kim@mongodb.com Kay Kim (Inactive)
            0 Vote for this issue
            2 Start watching this issue

              6 years, 6 weeks, 6 days ago