[SERVER-45800] Unlock RSTL after calling setLastOpToSystemLastOpTime in PrepareTransactionCmd Created: 27/Jan/20  Updated: 29/Oct/23  Resolved: 30/Jan/20

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

Type: Bug Priority: Major - P3
Reporter: Lingzhi Deng Assignee: Lingzhi Deng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-45598 Complete TODO listed in SERVER-39364 Closed
Problem/Incident
is caused by SERVER-39364 Audit uses of setLastOpToSystemLastOp... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2020-02-10
Participants:
Linked BF Score: 20

 Description   

After SERVER-39364, ReplClientInfo::setLastOpToSystemLastOpTime acquires a global IS lock and implicitly the RSTL lock in MODE IX. But when setLastOpToSystemLastOpTime is called on a retry of a prepared transaction, it breaks the contract that prepared transactions should not hold RSTL locks.

Updated: We dont have to call setLastOpToSystemLastOpTime, we can simply set client lastOp to max(prepareOpTime, lastAppliedOpTime)



 Comments   
Comment by Githook User [ 30/Jan/20 ]

Author:

{'name': 'Lingzhi Deng', 'username': 'ldennis', 'email': 'lingzhi.deng@mongodb.com'}

Message: SERVER-45800: Set client lastOp to max(prepareOpTime, lastAppliedOpTime, current lastOp) in PrepareTransactionCmd

create mode 100644 jstests/replsets/retrying_prepared_transaction_does_not_block_stepdown.js
Branch: master
https://github.com/mongodb/mongo/commit/c5cc18dd7484867d82959fc221eeb42efae94255

Generated at Thu Feb 08 05:09:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.