[SERVER-41165] Transaction participants don't need to do a noop write before committing a read-only transaction Created: 15/May/19 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ShardedTxn:FutureOptimizations | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently, TransactionParticipant::commitUnpreparedTransaction does a noop write after committing a read-only transaction, so that waiting for writeConcern waits for a Timestamp after the transaction's read Timestamp, to respect the isolation level requested by the client's writeConcern. Instead, it can just wait for writeConcern of the read Timestamp. |
| Comments |
| Comment by Esha Maharishi (Inactive) [ 28/May/19 ] |
|
judah.schvimer, tess.avitabile, this optimization is independent of any sharding machinery and can also apply to single replica set transactions. It was not a high priority in PM-564, but I think that's mainly because we were blocked on it. We passed it to repl since the repl team seemed to be solving related problems and had more context on when and how (and if) this optimization should be done. |
| Comment by Tess Avitabile (Inactive) [ 28/May/19 ] |
|
Since this optimization is only for transactions with snapshot readConcern, I don't think it is that valuable. We plan to schedule |
| Comment by Judah Schvimer [ 28/May/19 ] |
|
esha.maharishi, do you have any extra information on how this optimization was prioritized in PM-564 so we can triage it effectively? Also, is there any coordinator work necessary to make this work? |
| Comment by Tess Avitabile (Inactive) [ 21/May/19 ] |
|
Note that this optimization only applies to transactions with read concern snapshot, since local/majority transactions do not have a read timestamp. Local/majority transactions will still need to use a noop write until we have a general solution for |