[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: |
|
||||||||
| 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:
|
| Comments |
| Comment by Githook User [ 15/Oct/18 ] |
|
Author: {'name': 'Matthew Saltz', 'email': 'matthew.saltz@mongodb.com', 'username': 'saltzm'}Message: |
| Comment by Matthew Saltz (Inactive) [ 04/Oct/18 ] |
|
And I already did the second case (txnNumber is higher than the latest on session) in |
| 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. |