[SERVER-71938] Avoid applying commitTransaction entry individually if it refers to a prepare entry in the same batch Created: 07/Dec/22  Updated: 30/Mar/23  Resolved: 30/Mar/23

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

Type: Improvement Priority: Major - P3
Reporter: Wenbin Zhu Assignee: Backlog - Replication Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-72502 Implement oplog batcher changes for p... Closed
Assigned Teams:
Replication
Participants:

 Description   

With the current design, when the oplog batcher decides a commitTransaction oplog entry needs to be applied individually (OplogBatcher::mustProcessIndividually), it will check if the commitTransaction entry refers to a session in the SplitPrepareSessionManager, and will process it individually if not. However if the commitTransaction entry and the prepare entry it refers to come from the same batch, this check will always fail since we have yet called SplitPrepareSessionManager to split the session at this point.

This results in us unnecessarily apply certain commitTransaction entries in their own batch, although it's not very common to have the commitTransaction entry and the prepare entry it refers to coming from the same batch because the prepare must be majority committed before the commit command is run.

To avoid this, the oplog batcher needs save some state (either setting in itself or in SplitPrepareSessionManager) when it sees a prepare entry to indicate that there is a prepare to be split, and later when it sees a following commitTransaction entry in the same batch, it knows that it refers to a to-be-split prepare and that we can put it in the same batch with the prepare entry.



 Comments   
Comment by Wenbin Zhu [ 30/Mar/23 ]

We are not going to group commits/aborts with other prepares, closing.

Comment by Wenbin Zhu [ 18/Jan/23 ]

There is an additional caveat: once this is done, we could have multiple prepares for the same session in the same batch, e.g. [prepare, commit, prepare, commit]. When we dispatch the ops to the writer vectors, we need to call SplitPrepareSessionManager to create split sessions. However it currently disallows an already split top-level session to be split again without releasing. If we do this, we need to change that behavior to allow multiple splits on the same top-level session as long as they refer to different txnNumber's.

Generated at Thu Feb 08 06:20:22 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.