[SERVER-46378] Support continuing a transaction started by mongos (or different shard) on a shard Created: 24/Feb/20  Updated: 19/May/23  Resolved: 19/May/23

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

Type: Improvement Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Duplicate Votes: 0
Labels: sharding-common-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-48122 Support $unionWith in a transaction Backlog
is depended on by SERVER-45542 Support and test $unionWith aggregati... Backlog
is depended on by SERVER-46373 Allow an aggregation sub-operation on... Backlog
Duplicate
Assigned Teams:
Sharding NYC
Participants:

 Description   

As described in SERVER-46373, an aggregation pipeline may contain a stage which itself reads from a different collection from which the original command was run against. The remote requests for the sub-operation will generally fall into one of two buckets:

1. The targeted shard has already been contacted by mongos and already has knowledge of the transaction details. As long as the shard that's acting as a router correctly appends the txn information, then the recipient shard will respond to the query as if it was sent from mongos.
2. The targeted shard has not been contacted yet and thus has no knowledge of the transaction. In this case, the shard acting as a router needs to instruct the shard to start a new transaction. Currently mongos uses a startTransaction flag to achieve this. We could use a similar mechanism here, however blindly attaching the flag will not work due to the case described in (1) and there's a specific state machine that's expected for each participant.

Note that solving the above issue is half of the battle, as additional participants of the sub-operation need to be conveyed back to mongos to be used in the commit and readConcern enforcement.


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