[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:
Depends
depends on SERVER-39364 Audit uses of setLastOpToSystemLastOp... Closed
Related
related to SERVER-39489 Clarify optime creation in Transactio... Closed
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 SERVER-39364 early in 4.4, which will hopefully allow us to get rid of the noop write in all cases.

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 SERVER-39364.

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