[SERVER-37021] The TransactionCoordinatorService should validate the incoming transaction number and session id Created: 06/Sep/18  Updated: 29/Oct/23  Resolved: 15/Oct/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: 4.1.5

Type: Task Priority: Major - P3
Reporter: Matthew Saltz (Inactive) Assignee: Matthew Saltz (Inactive)
Resolution: Fixed Votes: 0
Labels: ShardedTxn:DistributedCommit, transaction-coordinator-management
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-37022 TransactionCoordinator should have an... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2018-10-08, Sharding 2018-10-22
Participants:

 Description   

The TransactionCoordinatorService should validate the incoming transaction number and session id against the latest transaction for the session. The logic should be as follows:

  • If there exists a latest transaction for this session:
    • If txnNumber is the same as the latest on the session:
      • uassert that the coordinator has not yet received any votes or coordinateCommit
    • If txnNumber is higher than the latest on the session:
      • Call "tryAbort" on the latest coordinator for the session


 Comments   
Comment by Githook User [ 15/Oct/18 ]

Author:

{'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com', 'username': 'saltzm'}

Message: SERVER-37021 Rely on TransactionParticipant validation of incoming transaction number when startTransaction is true
Branch: master
https://github.com/mongodb/mongo/commit/c16959b116f9ff4a438f987679a42919dcb4f91f

Comment by Matthew Saltz (Inactive) [ 04/Oct/18 ]

And I already did the second case (txnNumber is higher than the latest on session) in SERVER-37232 because it was required there.

Comment by Matthew Saltz (Inactive) [ 04/Oct/18 ]

For this ticket, after talking with jack.mulrow, we've decided that no additional validation is necessary from the TransactionCoordinatorService with respect to receiving a command with startTransaction = true and coordinator = true, since that validation is already handled by the TransactionParticipant that will be local to the coordinator shard. So, for this we only need to move the creation of the coordinator below this line. So, if createCoordinator is called on the TransactionCoordinatorService, we'll know that it's a valid case and so we can behave as we would normally behave when a new transaction comes in for a session with an existing transaction, and just try to abort the existing transaction before moving on to the next.

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