[SERVER-41881] Stashing the lock resources for prepared transactions by state transitions (step up/ step down) should not preserve the maxLockTimeout of the previous node's state. Created: 24/Jun/19  Updated: 29/Oct/23  Resolved: 25/Jul/19

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

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

Issue Links:
Backports
Related
related to SERVER-41556 Must handle failure to reacquire lock... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2
Sprint: Repl 2019-07-01, Repl 2019-07-15, Repl 2019-07-29
Participants:

 Description   

Consider the following state transitions.

Step down (primary to secondary).
1. Primary, stashes its lock resources for prepared transactions with maxLockTimeout set to non-zero value (by default it is 5ms) . And, its stash style is StashStyle::kPrimary.
2. Step down unstash the lock resources of prepared transactions from the transactionParticipant to its opCtx. Then, stashes the lock resources in StashStyle::kSecondary and preserving the maxLockTimeout value.
3. Now, the node state is secondary and if we try to apply a commit command for that transaction via secondary oplog application, we unstash the lock resource with maxLockTimeout set. Unstashing the lock resources will reacquire the yielded locks and reacquire the ticket with maxLockTimeout set. This can failĀ  and it can lead to server crash.

Step Up (Secondary to Primary).
1. Secondary, stashes its lock resources for prepared transactions with maxLockTimeout unset. And, its stash style is StashStyle::kSecondary.
2. Step Up unstash the lock resources of prepared transactions from the transactionParticipant to its opCtx. Then, stashes the lock resources in StashStyle::kPrimary and preserving the maxLockTimeout value.
3. Now, the node state is primary and if we try to apply a commit command for that transaction, we unstash the lock resource with maxLockTimeout unset. This means we reacquire the ticket with no maxLockTimeout. This means we are breaking the contract on transaction timeout.



 Comments   
Comment by Githook User [ 25/Jul/19 ]

Author:

{'name': 'Suganthi Mani', 'email': 'suganthi.mani@mongodb.com', 'username': 'smani87'}

Message: SERVER-41881 Unstashing the transaction lock resources should ignore the saved value of maxLockTimeout and explicitly set the maxLockTimeout based on node's state.
SERVER-41883 Replication state transition reacquires locks and tickets of a prepared transaction with no lock timeout.
SERVER-41556 Handles failure to reacquire locks and ticket when unstashing transactions.

(cherry picked from commit 2ff54098b19ebc2b4bbf5516de6e6befb46f9fe7)
Branch: v4.2
https://github.com/mongodb/mongo/commit/7be60542714d7cd17a6ecf5e43a47bb7aef9a0d5

Comment by Githook User [ 25/Jul/19 ]

Author:

{'name': 'Suganthi Mani', 'username': 'smani87', 'email': 'suganthi.mani@mongodb.com'}

Message: SERVER-41881 Unstashing the transaction lock resources should ignore the saved value of maxLockTimeout and explicitly set the maxLockTimeout based on node's state.
SERVER-41883 Replication state transition reacquires locks and tickets of a prepared transaction with no lock timeout.
SERVER-41556 Handles failure to reacquire locks and ticket when unstashing transactions.
Branch: master
https://github.com/mongodb/mongo/commit/2ff54098b19ebc2b4bbf5516de6e6befb46f9fe7

Comment by Githook User [ 23/Jul/19 ]

Author:

{'name': 'Ian Boros', 'email': 'puppyofkosh@gmail.com', 'username': 'puppyofkosh'}

Message: Revert "SERVER-41881 Unstashing the transaction lock resources should ignore the saved value of maxLockTimeout and explicitly set the maxLockTimeout based on node's state."

This reverts commit e707fd09ef0dadbb33510249732fd38c654da914.
Branch: v4.2
https://github.com/mongodb/mongo/commit/65a1db06e9a88e7d96e1359662f5480f939c0e5b

Comment by Githook User [ 23/Jul/19 ]

Author:

{'name': 'Ian Boros', 'email': 'puppyofkosh@gmail.com', 'username': 'puppyofkosh'}

Message: Revert "SERVER-41881 Unstashing the transaction lock resources should ignore the saved value of maxLockTimeout and explicitly set the maxLockTimeout based on node's state."

This reverts commit b7cec5064fb03f1e1f9bd39af35e495facfdcdc9.
Branch: master
https://github.com/mongodb/mongo/commit/38e92ef5b9fe645cd73fec3742c0fde9caea0cb2

Comment by Githook User [ 15/Jul/19 ]

Author:

{'name': 'Suganthi Mani', 'username': 'smani87', 'email': 'suganthi.mani@mongodb.com'}

Message: SERVER-41881 Unstashing the transaction lock resources should ignore the saved value of maxLockTimeout and explicitly set the maxLockTimeout based on node's state.
SERVER-41883 Replication state transition reacquires locks and tickets of a prepared transaction with no lock timeout.
SERVER-41556 Handles failure to reacquire locks and ticket when unstashing transactions.

(cherry picked from commit b7cec5064fb03f1e1f9bd39af35e495facfdcdc9)
Branch: v4.2
https://github.com/mongodb/mongo/commit/e707fd09ef0dadbb33510249732fd38c654da914

Comment by Githook User [ 15/Jul/19 ]

Author:

{'name': 'Suganthi Mani', 'email': 'suganthi.mani@mongodb.com', 'username': 'smani87'}

Message: SERVER-41881 Unstashing the transaction lock resources should ignore the saved value of maxLockTimeout and explicitly set the maxLockTimeout based on node's state.
SERVER-41883 Replication state transition reacquires locks and tickets of a prepared transaction with no lock timeout.
SERVER-41556 Handles failure to reacquire locks and ticket when unstashing transactions.
Branch: master
https://github.com/mongodb/mongo/commit/b7cec5064fb03f1e1f9bd39af35e495facfdcdc9

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