-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding EMEA 2022-09-19, Sharding EMEA 2022-10-03, Sharding EMEA 2022-10-17, Sharding EMEA 2022-10-31
-
132
Currently the CSS (collection sharding state) service is protected by a ResourceMutex, which is owned by the CSS itself. This means it is not possible to lock it before a reference to that service is obtained or from outside. This prevents implementing dropping and the lock-free concurrency control scenarios where we require several services to be kept in sync.
This ticket is to pull the locking of the CSS outside of the CSS object itself, so that it can be held locked for longer than the lifetime of the CSS. Furthermore, it will serve as an input to the "optimistic services snapshots" work later on, which needs to obtain a snapshot of everything about a collection in an atomic manner without holding locks.
This lock must be acquired always at a level-0, meaning it must be the last lock acquired.
It is either:
- Only the CSS lock by itself
- The db/collection locking hierarchy + DSS lock + CSS lock
- causes
-
SERVER-76652 createRandomCursorExecutor holds the CSSLock while potentially executing a TrialStage
- Closed
-
SERVER-71010 Initialize CollectionShardingStateFactory on BM_UnshardedDestinedRecipient
- Closed
-
SERVER-71081 Make ShardingWriteRouter instantiation a noop again for non-shardsvrs
- Closed
- depends on
-
SERVER-69434 Make the DSS acquisition a RAII
- Closed
-
SERVER-69893 Add the ability to acquire lock manager mutex resources by name
- Closed
- is depended on by
-
SERVER-69445 Implement the CollectionSnapshot(s) infrastructure to back CollectionPtr
- Closed