[SERVER-64506] Unify replication back-end of TransactionParticipant and WUOW Created: 15/Mar/22  Updated: 06/Dec/22

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

Type: Improvement Priority: Major - P3
Reporter: Josef Ahmad Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-68860 add container type to hold replicated... Closed
is related to SERVER-55909 Prevent a single WUOW from writing mu... Backlog
is related to SERVER-63047 Make delete batches fully transactional Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

Background:

  • At the time of writing, a WUOW does not replicate transactionally: a WUOW involving multiple document writes generates one oplog entry (and timestamp) per write. SERVER-55909 aims to address this issue, and make WUOW's replicate much like multi-document transactions.
  • SERVER-63047 implements SERVER-55909 for a specific use case - batching large deletions efficiently. It does so by introducing a BatchedWriteContext and plugging the WUOW commit into the OpObserver multi-document transaction commit logic.

We should unify the BatchedWriteContext and TransactionParticipant replication logic. This may also simplify the work needed for SERVER-55909.
Proposal: the TransactionParticipant should be using BatchedWriteContext to store operation state, rather than keeping it as private context on its own type, and then when we're stashing transactions between statements, we should be stashing the BWC as well. With this approach, we should also be in a position to unify the OpObserverImpl::onUnpreparedTransactionCommit and OpObserverImpl::onBatchedWriteCommit functions.


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