Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-64506

Unify replication back-end of TransactionParticipant and WUOW

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Backlog
    • Major - P3
    • Resolution: Unresolved
    • None
    • None
    • None
    • Storage Execution

    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.

      Attachments

        Issue Links

          Activity

            People

              backlog-server-execution Backlog - Storage Execution Team
              josef.ahmad@mongodb.com Josef Ahmad
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated: