The manual claims that 2-phase commit is used for changes to config servers. A property that 2-phase commit provides is that changes are not visible on any of the servers until all servers have agreed to commit. From reading source in src/mongo/s and src/mongo/s/catalog I don't see how that is provided.

Assuming I am correct, can the manual be updated to explain the behavior that is provided?

What I do see is this pattern for updates which runs in two phases but isn't 2-phase commit:
1) ping all config servers to confirm they are running
2) send write to all config servers
3) collect responses from writes. If all fail, then report that (which is OK). If all succeed then report OK. Else report inconsistent write because write was done to some but not all config servers.

Two questions:
1) Is there code to cleanup from inconsistent write? Cleanup code won't avoid the race from inconsistent reads, but will shrink the window.

2) What is done to avoid inconsistent read after inconsistent write? If this were 2-phase commit then inconsistent read (read after inconsistent write) wouldn't be possible.

Code I read to understand this includes:

• CatalogManagerLegacy::writeConfigServerDirect
• ConfigCoordinator::executeBatch
• SSVRequest::combineResponses
• DBClientMultiCommand::sendAll