[SERVER-40123] Transaction diagnostics should not report upconverted readConcern Created: 14/Mar/19  Updated: 22/Aug/19  Resolved: 22/Aug/19

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

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

Issue Links:
Duplicate
duplicates SERVER-41359 Stop upconverting readConcern to snap... Closed
Related
related to SERVER-41359 Stop upconverting readConcern to snap... Closed
is related to SERVER-35821 readConcern:snapshot transactions nee... Closed
is related to SERVER-34837 Make the default readConcern level fo... Backlog
Operating System: ALL
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
Participants:

 Description   

Transaction diagnostics report that all transactions execute with readConcern level snapshot, since originally we intended to upconvert the readConcern to snapshot for all single replica set transactions. However, this is false, since as we saw in SERVER-35821, transactions with readConcern level majority and local do not execute with snapshot isolation. This difference will be more pronounced with multi-shard transactions, where we only select the same read timestamp across shards if the requested readConcern level is snapshot. Transaction diagnostics should now report the requested readConcern level.

There is a question of what to report when no readConcern was specified, since we intend to change the default readConcern from local to (speculative) majority in SERVER-34837. We could report no readConcern for these transactions, since no readConcern was requested.



 Comments   
Comment by Tess Avitabile (Inactive) [ 28/Mar/19 ]

That was the original intention of reporting the read concern as snapshot, since we were upconverting all transactions to use snapshot read concern. However, now the behaviors of the different read concern levels are different, so we should be reporting the user's requested read concern.

Comment by Bruce Lucas (Inactive) [ 28/Mar/19 ]

Would it make sense to also report in a separate field the actual read concern used, if it differs from what was requested (including the case where none was specified)?

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