[SERVER-42388] Release the transaction lock resources and abort storage transaction for unprepared transactions on failure to unstash the transaction resources to opCtx. Created: 24/Jul/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.2.0-rc5, 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
Depends
Duplicate
is duplicated by SERVER-42381 A failed unstashTransactionResources ... Closed
Related
related to SERVER-41556 Must handle failure to reacquire lock... Closed
is related to SERVER-42404 Merge beginOrContinue() and unstashTr... Backlog
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2, v4.0
Sprint: Repl 2019-07-29
Participants:
Linked BF Score: 17

 Description   

Currently, for any exception thrown after beginOrContinue and before unstashTransactionResources finishes, we don't abort the unprepared transactions implicitly. Instead we wait for it to abort eventually, either by the transaction reaper or any future requests with higher transaction number. To be noted, reaper would only abort the expired transactions and their life time of the transaction is controlled by an user defined server parameter transactionLifetimeLimitSeconds. As a result, we are holding the transaction lock and storage resources for an unbounded period of time that would make other DDL/CRUD operations to starve. So, it's good to reclaim the lock and storage resources early from the failed transaction.

Note: Any individual statements in a transaction other than commit/abort cmd are definitely not retryable even if we attach a retyable error code as we attach TransientTransaction Error (TTE) label to it. TTE signals that it's safe to retry the entire transaction.



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

Author:

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

Message: SERVER-42388 Release the transaction lock resources and abort storage
transaction for unprepared transactions on failure to unstash the
transaction resources to opCtx.

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

Comment by Githook User [ 25/Jul/19 ]

Author:

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

Message: SERVER-42388 Release the transaction lock resources and abort storage
transaction for unprepared transactions on failure to unstash the
transaction resources to opCtx.
Branch: master
https://github.com/mongodb/mongo/commit/f5f62f877b62523205d02f810f351b06cf1e58c4

Comment by Suganthi Mani [ 24/Jul/19 ]

Consider a case where we accidentally ran into executing an invalid statement/cmd in a transaction, this means we would abort the entire transaction. So, its not safe to wrap beginOrContinue in an errorGuard (aborts the transaction). Below are the js tests that explicitly test the above behavior.
1) multi_statement_transaction_command_args.js
2) no_read_or_write_concern_inside_txn.js
3) prepare_nonexistent_transaction.js

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