[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: |
|
||||||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
|
| 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:
and one that looks like:
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. |