[SERVER-34881] Don't wait for writeConcern when committing a read-only transaction with readConcern: 'local' Created: 07/May/18  Updated: 06/Dec/22

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

Type: Task Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: open_todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-34837 Make the default readConcern level fo... Backlog
Related
is related to SERVER-34038 Make sure that commitTransaction wait... Closed
is related to SERVER-34880 Make readConcern:local wait for write... Closed
Assigned Teams:
Replication
Participants:

 Description   

SERVER-34880 undid this behavior, pending the fix for SERVER-34837.  Once SERVER-34837 is fixed, we should revert the changes from SERVER-34880



 Comments   
Comment by Andy Schwerin [ 12/Mar/20 ]

I agree with geert.bosch and tess.avitabile. Does that make this ticket "Works as Designed"? I'm a little turned around.

Comment by Tess Avitabile (Inactive) [ 28/Feb/20 ]

Geert's argument is no. There should be no difference between a transaction that looks like:

findAndModify(...)

and one that looks like:

let x = find(...)
if (x == 0)
    update(...)

I agree with him. These should do the same thing.

Comment by Judah Schvimer [ 28/Feb/20 ]

We can distinguish a transaction that does not attempt to do a write and one that attempts to do a write but does a noop write. Should those be different in this case? Should the truly read-only transaction no wait for write concern if read concern is local, but a transaction with a noop write would wait for write concern no matter the read concern?

Comment by Tess Avitabile (Inactive) [ 28/Feb/20 ]

geert.bosch and I just discussed this ticket, and now I'm considering whether this should be closed as Works As Designed. His argument is that regardless of the readConcern, a noop write should wait for writeConcern. In a transaction, that noop write can take the form of a findAndModify or a find command that led to a decision not to write.

I'm not sure what the correct answer is. Certainly, it's important that the default behavior is that a noop write waits for writeConcern, which is why we made the default behavior of readConcern in transactions to be speculative majority (for now this is done by making local and majority behave the same, in the future we would make this explicit in SERVER-34837). Another consideration is that if we stop waiting for writeConcern for read-only transactions with readConcern local, we would want to ensure the behavior is consistent between find and findAndModify. So the question is whether we want to provide a readConcern offering that does not wait for writeConcern at commit time if no writes were performed. Maybe the anomaly with noop writes means we don't want to provide this consistency offering at all.

CC schwerin

Comment by Ratika Gandhi [ 28/Jun/19 ]

samy.lanka, moving this ticket out of the Address Tech Debt transactions epic. It will require scoping, competitive analysis and prioritization. 

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