-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding EMEA 2022-09-19
-
130
Currently the DSS (database sharding state) service is protected by a ResourceMutex, which is owned by the DSS 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 DSS outside of the DSS object itself, so that it can be held locked for longer than the lifetime of the DSS. 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 or 1, meaning it must be the last lock acquired or the second to last, with the last being the CSS lock.
It is either:
- Only the DSS lock by itself
- Only DSS lock + CSS lock
- The db/collection locking hierarchy + DSS lock + CSS lock
- causes
-
SERVER-70154 DatabaseShardingState inappropriately constructs a RESOURCE_MUTEX ResourceId, leading to uncaught exception
- Closed
- depends on
-
SERVER-69444 Make the joining of concurrent critical section and refresh look the same between DSS and CSS
- Closed
- is depended on by
-
SERVER-69435 Make the CSS acquisition a RAII
- Closed
-
SERVER-69445 Implement the CollectionSnapshot(s) infrastructure to back CollectionPtr
- Closed
- is related to
-
SERVER-70198 Use one single RESOURCE_MUTEX to protect concurrent operations on DatabaseShardingState for all databases
- Closed