The RoutingContext API will be the interface through which query code obtains cached routing tables. It is part of the RouterRole API and should handle:
- Providing a mapping between each requested NamespaceString and its associated routing table
- Ensuring that the mapping is immutable. The CatalogCache should only be accessed once for the routing tables during creation, and never again throughout a routing operation.
- Acquiring the appropriate routing table depending on the read concern. The latest routing table is sufficient in most cases, but if the read concern is snapshot with atClusterTime is set, the routing tables should reflect their atClusterTime state.
For now, the RoutingContext will just take in the required namespaces and read concern as input. It will later be integrated with the RouterAcquisitionSnapshot.
- is depended on by
-
SERVER-102925 Replace direct CatalogCache accesses in the sharded aggregation code with the RoutingContext
-
- In Progress
-
-
SERVER-102926 Replace direct CatalogCache accesses in the sharded query command code with the RoutingContext
-
- Closed
-
-
SERVER-102928 Validate the RoutingContext before termination
-
- Closed
-
-
SERVER-102929 Replace direct CatalogCache accesses in remaining query owned code with the RoutingContext
-
- Needs Scheduling
-
-
SERVER-102931 Integrate CollectionIncarnationSnapshot with RoutingContext
-
- Needs Scheduling
-
- related to
-
SERVER-103419 Avoid timeout in RoutingContextPropagatesCatalogCacheErrors
-
- Closed
-