[SERVER-38094] Send prepareTransaction with write concern that waits for majority commit point but not committed snapshot Created: 12/Nov/18  Updated: 29/Oct/23  Resolved: 15/Nov/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.1.6

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: ShardedTxn:DistributedCommit, ShardedTxn:Testing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Gantt Dependency
has to be done before SERVER-38025 Remove uses_transactions tag blacklis... Closed
Problem/Incident
Related
is related to SERVER-37976 Transaction coordinator should wait f... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2018-11-19
Participants:
Linked BF Score: 60

 Description   

As of SERVER-35811, the stable timestamp is not allowed to advance beyond the opTime of the prepare oplog entry of the oldest non-committed/aborted transaction, which means the prepareTransaction command cannot satisfy majority write concern until all earlier prepared transactions have committed or aborted (because majority wc waits for the committed snapshot to advance, which is tied to the stable timestamp). This is a problem for cross-shard transactions because the coordinator shard sends prepareTransaction to all participant shards with majority write concern and will not make a commit decision until it hears responses from each (or times out and aborts). So if two cross shard transactions involve two of the same shards and their prepare oplog entries are in different orders on those shards, neither coordinator will receive all of the responses it needs to make a decision, and the transactions will deadlock until at least one times out.

To work around this, each transaction coordinator can send prepareTransaction with a new write concern that waits for the prepare entry to be majority committed, but not in the committed snapshot, so write concern can be satisfied without waiting for the stable timestamp to advance, but the entry still cannot be rolled back.



 Comments   
Comment by Githook User [ 03/Apr/19 ]

Author:

{'name': 'Suganthi Mani', 'username': 'smani87', 'email': 'suganthi.mani@mongodb.com'}

Message: SERVER-39041 Revert "SERVER-38094 Add write concern that waits for majority commit point but not committed snapshot"

This reverts commit 922e2f27c087cc017bb612a5c86eedb2cfa52a75.
Branch: master
https://github.com/mongodb/mongo/commit/445dcfe70310303713184181919689485a158cd0

Comment by Githook User [ 19/Nov/18 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-38094 Skip majorityNoSnapshot jstest if storage engine doesn't support majority read concern
Branch: master
https://github.com/mongodb/mongo/commit/ac2880e51b9b540a24f9babc632a89c23d0b51b4

Comment by Githook User [ 15/Nov/18 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-38094 Send prepareTransaction with write concern that only waits for majority commit point
Branch: master
https://github.com/mongodb/mongo/commit/98c411aac146b85898af737ebe3dac5cf98b5d9e

Comment by Githook User [ 15/Nov/18 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-38094 Add write concern that waits for majority commit point but not committed snapshot
Branch: master
https://github.com/mongodb/mongo/commit/922e2f27c087cc017bb612a5c86eedb2cfa52a75

Generated at Thu Feb 08 04:47:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.