Details
-
Task
-
Resolution: Duplicate
-
Major - P3
-
None
-
3.5.11
-
None
-
Sharding 2017-08-21
Description
We had attempted to allow the CatalogCache to accept readConcern local, so that metadata commands running on the config server which end with a majority write can read the most fresh data by using readConcern local. If they had used readConcern majority, they could possibly read stale data.
However, the CatalogCache refresh happens on one thread, and any other threads reading from the cache block behind this thread. This means the other threads will get data at the readConcern of the first thread; their own readConcern arguments are ignored.
It is fairly complex to make the CatalogCache take a readConcern, especially since the CatalogCache is a shared component across mongos, shards, and the config server. The uses of the CatalogCache across and within each of these have varying readConcern needs.
So, this ticket is to revert the parts of SERVER-30219 that make the CatalogCache take a readConcern. The CatalogCache should instead use majority readConcern everywhere, which preserves the 3.4 behavior.