[SERVER-37481] Add testing to interleave prepared transactions applyOps oplog entry replay and the corresponding write to the transactions table Created: 05/Oct/18  Updated: 06/Dec/22  Resolved: 17/May/19

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

Type: Improvement Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: prepare_optional, prepare_testing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-36538 Create idempotency tests for prepare,... Closed
is related to SERVER-35880 Apply ops within a prepare oplog entr... Closed
Assigned Teams:
Replication
Participants:

 Description   

The transaction prepare and following commit logic contains some pretty tricky combination of oplog writes in different WUsOW (i.e., the actual applyOps oplog write, the write which changes the state to prepared and writes down the prepare timestamp and the final commit oplog entry write, which ensures visibility).

Due to the concurrency of the applier threads on the secondaries, these oplog entries can be applied in different order, potentially causing interesting race conditions.

We could potentially make this logic more robust by adding some testing flag or replication failpont to the applier logic, to cause different interleaving between the applyOps and the updates to the transactions table.

The simplest thing would be to make all updates to the transactions table to happen before everything else in one test and after everything else in another. This should be enough to shake out any race condition bugs.



 Comments   
Comment by Gregory McKeon (Inactive) [ 17/May/19 ]

Our concurrency testing gives us similar coverage.

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