[SERVER-72988] Retryable bulkWrite on mongod Created: 18/Jan/23 Updated: 29/Oct/23 Resolved: 13/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Lingzhi Deng | Assignee: | Sean Zimmerman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | milestone-3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Repl 2023-04-17 |
| Participants: |
| Description |
|
On mongod, when we receive a bulkWrite command under retryable writes, we already have logic at the service entry point layer to set up opCtx with sessionInfo, validate it and check out the session. The only thing we need to do to support retryable writes is to leverage helper functions in OperationContext/TransactionParticipant to check if a statement has already been executed, attach lsid, txnNumber and stmtId(s) when building the oplog chain for each operation or extract the original response from the existing oplog chain.
Mongod also needs to use similar logic to batch writes to assign the correct stmtId(s) per every individual op we process. Update and delete should follow the logic of findAndModify |
| Comments |
| Comment by Githook User [ 13/Apr/23 ] |
|
Author: {'name': 'seanzimm', 'email': 'sean.zimmerman@mongodb.com', 'username': 'seanzimm'}Message: |