[SERVER-40466] Unify checks for inMultiDocumentTransaction and friends Created: 03/Apr/19  Updated: 29/Oct/23  Resolved: 08/Aug/19

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

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Samyukta Lanka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by SERVER-41359 Stop upconverting readConcern to snap... Closed
Problem/Incident
Related
is related to SERVER-39627 Audit uses of TransactionParticipant:... Closed
is related to SERVER-42750 OperationContext::inMultiDocumentTran... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.2
Sprint: Repl 2019-07-01, Repl 2019-07-15, Repl 2019-07-29, Repl 2019-08-12
Participants:
Linked BF Score: 12

 Description   

There are multiple ways of checking if an opCtx is in a multi-document transaction. They're each slightly different in practice and we use them somewhat interchangeably. We should clarify the semantic differences between these three, make sure that any place that uses one is using the correct one, and make it clearer what to do in the future.

Ways to check:

  1. inMultiDocumentTransaction
  2. seeing if the opCtx has a top level WUOW
  3. checking if the read concern on the opCtx is "snapshot"


 Comments   
Comment by Githook User [ 24/Sep/19 ]

Author:

{'name': 'Samyukta Lanka', 'username': 'lankas', 'email': 'samy.lanka@mongodb.com'}

Message: SERVER-40466 Unify checks for being in a multi-document transaction

(cherry picked from commit 77967c90b1a521108c052af235ce7de9742aa95e)

SERVER-42755 recover_prepared_txn_with_multikey_write.js should verify absence of prepare conflicts on catalog after restart.

(cherry picked from commit eaf81228328738b685532c7eb10f833362434061)

SERVER-42750 Set opCtx->inMultiDocumentTransaction() in transaction recovery.

(cherry picked from commit 16c17677704a4f979381d593106a0c356088fd30)
Branch: v4.2
https://github.com/mongodb/mongo/commit/1781933c126d2aff697cdb42a8f84b8212db23ad

Comment by Githook User [ 08/Aug/19 ]

Author:

{'name': 'Samy Lanka', 'username': 'lankas', 'email': 'samy.lanka@mongodb.com'}

Message: SERVER-40466 Unify checks for being in a multi-document transaction
Branch: master
https://github.com/mongodb/mongo/commit/77967c90b1a521108c052af235ce7de9742aa95e

Comment by Samyukta Lanka [ 11/Jul/19 ]

code review: https://mongodbcr.appspot.com/494120003/

Comment by Tess Avitabile (Inactive) [ 29/May/19 ]

Great! I'll put up a patch today. If it can get in before I go on leave, great. If not, we can triage it with the Tech Debt work for someone to get it over the line.

Comment by Judah Schvimer [ 29/May/19 ]

That all sounds good to me! Should we use this ticket for changing all uses according to the semantics you've proposed and rank it in with the "Tech Debt" project?

Comment by Tess Avitabile (Inactive) [ 29/May/19 ]

I don't believe there are any bugs here, but we could do some cleanup. The semantics of these three checks are as follows:

  • inMultiDocumentTransaction(): This is true for transactions in states in-progress or prepared, regardless of whether the transaction resources are stashed in a SideTransactionBlock.
  • Seeing if the opCtx has a top-level WUOW: This is true for transactions in states in-progress or prepared, with two exceptions: (1) We are in a SideTransactionBlock, (2) We are not between the calls to unstashTransactionResources() and stashTransactionResources() in invokeWithSessionCheckedOut(). The first is significant. The second is not too significant, since unstashing and stashing happens very close to checking out and checking in the session.
  • Checking if the readConcern level on the opCtx is "snapshot": This is true throughout a transaction's lifetime, regardless of whether the transaction resources are stashed in a SideTransactionBlock, but only after the call to unstashTransactionResources().

My recommendation is to make inMultiDocumentTransaction() the canonical way to check whether we are in a transaction, unless that check must be sensitive to SideTransactionBlock, in which case we should check if the opCtx has a top-level WUOW. We should never check the readConcern level to determine whether we are in a transaction (and making that change will allow us to more easily implement SERVER-41359).

It would additionally be valuable to remove inActiveOrKilledMultiDocumentTransaction(), but that work can be done in SERVER-39614.

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