Certain aggregation stages involve sub-operations or sub-pipelines, which may involve targetting and reading from sharded collections when running on a shard (e.g. $lookup, $unionWith). Supporting such stages in a transaction would cause a deadlock on the session mutex if the sub-operation targets the same node its running on, similar to what is described in SERVER-33683. Note that SERVER-33683 allows a $mergeCursors to run on a shard in a txn, but does not support the case when a stage starts its own sub-operation.
For this ticket, one possible solution that was discussed would be to use the resource yielder that was built in SERVER-33683 within the MultiStatementTransactionRequestsSender if one of the remote shards involved happens to be itself.
- depends on
-
SERVER-46378 Support continuing a transaction started by mongos (or different shard) on a shard
-
- Closed
-
- is depended on by
-
SERVER-48122 Support $unionWith in a transaction
-
- Closed
-
-
SERVER-45542 Support and test $unionWith aggregation stage within a transaction
-
- Backlog
-
- related to
-
SERVER-84470 Allow $lookup to target an unsplittable collection on a primary shard within a multi-document transaction
-
- Closed
-
-
-
- Backlog
-