[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: |
|
||||||||||||||||||||||||||||
| 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: (cherry picked from commit f5f62f877b62523205d02f810f351b06cf1e58c4) |
| Comment by Githook User [ 25/Jul/19 ] |
|
Author: {'name': 'Suganthi Mani', 'username': 'smani87', 'email': 'suganthi.mani@mongodb.com'}Message: |
| 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. |