[SERVER-54402] CollectionShardingState and DatabaseShardingState should return immutable const references for lock-free read operations Created: 08/Feb/21  Updated: 30/May/23  Resolved: 30/May/23

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

Type: Improvement Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: [DO NOT USE] Backlog - Sharding EMEA
Resolution: Won't Fix Votes: 0
Labels: PM-2144-Milestone-0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by SERVER-53257 Determine whether we need const Colle... Closed
Related
related to SERVER-51319 Check DatabaseShardingState::checkDbV... Closed
Assigned Teams:
Sharding EMEA
Participants:

 Description   

This was attempted in SERVER-51319. However, there are existing interface obstructions wherein const CSS and DSS instances are not accepted and accommodation must be made: for example, the CSSLock related code interface needs expansion to accept const instances. Currently the lock-free read access functions are called DSS/CSS::getSharedForLockFreeReads(): they should return a const object.

This would prevent ostensible readers from running CSS functions that may modify the CSS or other sub-state, which is not currently protected against. Sharding may want to consider changes to the CSS and/or DSS classes and subsystems such that there can be const readers and non-const writers such that readers will not be allowed/able to do something they should not by accident.

-----------------------------------------------------------------------------

Some context-y notes:

  • Query has a use case for doing an aggregation on a view namespace wherein they must check whether the underlying collection is sharded or not — an optimization to reduce round trips between mongos and shard. Aggregation is running lock-free, so I recommended using CSS::getSharedForLockFreeReads() that bypasses the collection lock requirements for lock-free read operations. It seems likely that we will have an increasing need to access the CSS without collection locks, especially down the line when Execution runs more projects to remove locks from more operations.
  • The DatabaseShardingState and CollectionShardingState classes are considered global and unversioned state, I believe, merely accessors for various sharding state. Therefore, it would be best to be able to safely fetch versioned state THROUGH the DSS and CSS objects, to then stash for a lock-free read operation to use until finished.
    • An alternative would be to make these classes copy-on-write, so a lock-free read can grab a versioned instance of the CSS or DSS, but that doesn’t seem desirable from past conversations.
    • As a note, the execution layer Collection class is copy-on-write and can have several Collection instances for a single collection. Furthermore, a Collection instance can have versioned decorations OR unversioned shared decorations via decorating the ShardCollectionDecorations that exists as shared state across all Collection instances for a single collection.


 Comments   
Comment by Kaloian Manassiev [ 30/May/23 ]

As part of this project we are going in the direction of hiding the DSS/CSS, so this ticket is now unnecessary.

Generated at Thu Feb 08 05:33:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.