[SERVER-30545] make CatalogCache and its subcomponents always use readConcern=majority Created: 07/Aug/17  Updated: 08/Aug/17  Resolved: 08/Aug/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.11
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Sharding 2017-08-21
Participants:

 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.



 Comments   
Comment by Esha Maharishi (Inactive) [ 08/Aug/17 ]

Fixed by reverting SERVER-30219

Generated at Thu Feb 08 04:24:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.