[SERVER-34038] Make sure that commitTransaction waits for writeConcern after a read-only transaction Created: 21/Mar/18  Updated: 29/Oct/23  Resolved: 03/May/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.0.0-rc0

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

Issue Links:
Depends
Problem/Incident
Related
related to SERVER-34004 Support commitTransaction and abortTr... Closed
related to SERVER-34881 Don't wait for writeConcern when comm... Backlog
related to SERVER-34195 Support speculative readConcern behav... Closed
is related to SERVER-34880 Make readConcern:local wait for write... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-04-23, Repl 2018-05-07
Participants:
Linked BF Score: 18

 Description   

A read-only transaction running at speculative majority or speculative snapshot will read its data from the most recent snapshot. It then will need to wait at commit time to ensure that the data it read is committed. We can do this by remembering the optime that the read transaction started with and then setting the last OpTime on the Client object to that optime in the commitTransaction command body.



 Comments   
Comment by Githook User [ 03/May/18 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-34038 Make sure that commitTransaction waits for writeConcern after a read-only transaction.

This also ensures we can obtain a local snapshot when starting a transaction, by starting the
transaction before allowing the local snapshot to move forward.
Branch: master
https://github.com/mongodb/mongo/commit/217a8a4f3129e098d56f415903a49aa0c664f638

Comment by Tess Avitabile (Inactive) [ 20/Apr/18 ]

I think we will also need to remember the original readConcern, since we do not do that today.

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