[SERVER-41359] Stop upconverting readConcern to snapshot internally for transactions Created: 29/May/19  Updated: 29/Oct/23  Resolved: 03/Sep/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.3.1

Type: Improvement Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Samyukta Lanka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-40466 Unify checks for inMultiDocumentTrans... Closed
Duplicate
is duplicated by SERVER-40123 Transaction diagnostics should not re... Closed
Problem/Incident
Related
is related to SERVER-40123 Transaction diagnostics should not re... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2019-06-17, Repl 2019-07-01, Repl 2019-07-15, Repl 2019-07-29, Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09
Participants:
Linked BF Score: 0

 Description   

Initially, we planned that all multi-document transactions would run at readConcern level snapshot. However, over time the behavior for different readConcern levels within transactions has changed, and we have needed to check the original readConcern level to make decisions, such as what read source to use. It no longer seems to improve simplicity or readability of the code to internally upconvert the readConcern level to snapshot, and it has led to bugs, such as SERVER-40123.



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

Author:

{'username': 'lankas', 'email': 'samy.lanka@mongodb.com', 'name': 'Samyukta Lanka'}

Message: SERVER-41359 Stop upconverting readConcern to snapshot internally for transactions
Branch: master
https://github.com/mongodb/mongo/commit/720e7b216316eac5f5dc18f26684cd2ca1ed17e2

Comment by Githook User [ 03/Sep/19 ]

Author:

{'username': 'lankas', 'email': 'samy.lanka@mongodb.com', 'name': 'Samyukta Lanka'}

Message: SERVER-41359 Stop upconverting readConcern to snapshot internally for transactions
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/117d6441527ce4467f66ac4d62242208cc21e055

Comment by A. Jesse Jiryu Davis [ 07/Aug/19 ]

I believe this ticket will be an internal code cleanup, with no behavioral change. The code cleanup will protect us from repeating mistakes like SERVER-39672 in the future.

Comment by Alyson Cabral (Inactive) [ 07/Aug/19 ]

How is this ticket different than SERVER-39672 ?

CC: jesse@mongodb.com , siyuan.zhou

Comment by Tess Avitabile (Inactive) [ 30/May/19 ]

As part of this work, we will need to remove places in the code that check for kSnapshotReadConcern as a proxy for testing whether we are in a multi-document transaction. I did this in a WIP patch for SERVER-40466, but I ran into linking problems, since it was not possible to link the TransactionParticipant everywhere it was needed. We may need to add an OperationContext flag/decoration that indicates whether a statement is run as part of a multi-document transaction in order to avoid the linking problems.

Comment by Tess Avitabile (Inactive) [ 29/May/19 ]

This work will involve examining waitForReadConcern(), AutoGetCollection(), and AutoGetCollectionForRead(), which may make assumptions that snapshot read concern is synonymous with multi-document transactions.

Comment by Tess Avitabile (Inactive) [ 29/May/19 ]

This work depends on SERVER-40466, which will ensure that we do not check whether the readConcern level is snapshot as a proxy for checking whether we are in a multi-document transaction.

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