[DOCS-15386] [Server] Change server parameter to default to read-your-writes behavior after 2PC transaction Created: 01/Jun/22  Updated: 13/Nov/23  Resolved: 12/Oct/22

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: 6.1.0
Fix Version/s: 6.1.0-rc0, 5.0.10, 6.0.0-rc9, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Dave Cuthbert (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-63971 Change server parameter to default to... Closed
Participants:
Days since reply: 1 year, 8 weeks, 2 days ago
Epic Link: DOCSP-21764

 Description   

From: Investigate changes in SERVER-63971:

--------

Original Downstream Change Summary

coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter now defaults to false. It looks like it is mentioned in the transactions page (https://www.mongodb.com/docs/v5.0/core/transactions) and server parameters page.

Description of Linked Ticket

Currently, the coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter added in SERVER-37364 defaults to true, meaning a user may not get read-your-writes behavior even when using readPreference primary in the following cases:

  • User does a 2PC transaction (with a write, and within a session)
  • User tries to read the write it just did using a read
    • (1) outside a session, or
    • (2) in a different session, or
    • (3) outside a transaction in the same session without causal consistency.

If (4) the user did the read in a new transaction in the same session (regardless of causal consistency), the read is guaranteed to return the write, because the new transaction would block until the earlier transaction had committed on the transaction participant.

If (5) the user did the read outside a transaction in the same session but with causal consistency, I think the read would return the write, because the read's afterClusterTime would be >= the operationTime returned for the earlier transaction's commitTransaction >= the transaction's commitTimestamp >= the prepareTimestamp on any transaction participant. I think the storage engine would not allow reading a document that's in prepare at a timestamp >= the document's prepareTimestamp.

Since we in general try to preserve read-your-writes behavior when using readPreference primary, we may want to make coordinateCommitReturnImmediatelyAfterPersistingDecision default to false. Preserving read-your-writes is also a sensible default in Serverless.

If we make this change, we may want to improve documentation for coordinateCommitReturnImmediatelyAfterPersistingDecision for users who want to set it to true.

CC judah.schvimer , tess.avitabile


Acceptance criteria:

  • Change the server parameter value to false.
  • Audit what test coverage we have for coordinateCommitReturnImmediatelyAfterPersistingDecision=true to ensure we aren't losing all of our test coverage for the commitTransaction optimization. We generally aim to test the server's default behavior but having one concurrency suite running with the commitTransaction optimization on would be worthwhile.


 Comments   
Comment by Githook User [ 12/Dec/22 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-15386 server parameter update (#1987)

  • Staging updates
  • Staging updates
  • Staging updates
  • Review feedback
  • Review feedback
Comment by Githook User [ 12/Oct/22 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-15386 BACKPORT (#1997)

  • Staging updates
  • Staging updates
  • Staging updates
  • Review feedback
  • Review feedback
  • Review feedback
Comment by Githook User [ 12/Oct/22 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-15386 BACKPORT (#1996)

  • Staging updates
  • Staging updates
  • Staging updates
  • Review feedback
  • Review feedback
  • Review feedback
Comment by Githook User [ 11/Oct/22 ]

Author:

{'name': 'Dave Cuthbert', 'email': '69165704+davemungo@users.noreply.github.com', 'username': 'davemungo'}

Message: DOCS-15386 server parameter update (#1987)

  • Staging updates
  • Staging updates
  • Staging updates
  • Review feedback
  • Review feedback
Comment by Education Bot [ 03/Jun/22 ]

Fix Version updated for upstream SERVER-63971:
6.1.0-rc0, 5.0.10, 6.0.0-rc9

Comment by Education Bot [ 03/Jun/22 ]

Fix Version updated for upstream SERVER-63971:
6.1.0-rc0, 5.0.10

Comment by Education Bot [ 01/Jun/22 ]

Fix Version updated for upstream SERVER-63971:
6.1.0-rc0

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