Project: MongoDB (App Definition and Development / Database)
File: command_dispatch.md

Command dispatch refers to the general process by which client requests are taken from the network, parsed, sanitized, then finally run on databases. fulfill the transition from the transport layer into command implementations. For each incoming connection from a client (in the form of a object), a new dedicated thread is spawned then detached, and is also assigned a new [session workflow] [sessionworkflowh], responsible for maintaining the workflow of a single client connection during its lifetime. Central to the entry point is the `handleRequest()` function, which manages the server-side logic of processing requests and returns a response message indicating the result of the corresponding request message. This function is currently implemented by several subclasses of the parent `ServiceEntryPoint` in order to account for the differences in processing requests between mongod and mongos -- these distinctions are reflected in the `ServiceEntryPointMongos` and `ServiceEntryPointMongod` subclasses (see and ). One such distinction is the mongod entry point's use of the `ServiceEntryPointCommon::Hooks` interface, which provides greater flexibility in modifying the entry point's behavior. This includes waiting on a read of a particular level to be completed, as well as determining whether a read concern can indeed by satisfied given the current state of the server. Similar functionality exists for as well. One area in which the mongos entry point differs from its mongod counterpart is in its usage of the . `Strategy` operates as a legacy interface for processing client read, write, and command requests; there is a near 1-to-1 mapping between its constituent functions and request types (e.g. `writeOp()` for handling write operation requests, `getMore()` for a getMore request, etc.). These functions comprise the backbone of the mongos entry point's `handleRequest()` -- that is to say, when a valid request is received, it is sieved and ultimately passed along to the appropriate Strategy class member function. The significance of using the Strategy class specifically with the mongos entry point is that it [facilitates query routing to shards][mongosrouter] in addition_ to running queries against targeted databases (see for finer details). The serves as a means of cataloging a server command as well as ascribing various attributes and behaviors to commands via the [type system][templatemethodpattern], that will likely be used during the lifespan of a particular server. Construction of a Command should only occur during server startup. When a new Command is constructed, that Command is stored in a global `CommandRegistry` object for future reference. There are two kinds of Command subclasses: `BasicCommand` and `TypedCommand`. A major distinction between the two is in their implementation of the `parse()` member function. `parse()` takes in a request and returns a handle to a single invocation of a particular Command (represented by a `CommandInvocation`), that can then be used to run the Command. The `BasicCommand::parse()` is a naive implementation that merely forwards incoming requests to the Invocation and makes sure that the Command does not support document sequences. The implementation of `TypedCommand::parse()`, on the other hand, varies depending on the Request type parameter the Command takes in. Since the `TypedCommand` accepts requests generated by IDL, the parsing function associated with a usable Request type must allow it to be parsed as an IDL command. In handling requests, both the mongos and mongod entry points interact with the Command subclasses through the `CommandHelpers` struct in order to parse requests and ultimately run them as Commands. For details on transport internals, including ingress networking, see .