-
Type:
Task
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
CAR Team 2025-03-03, CAR Team 2025-03-17, CAR Team 2025-03-31
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In SERVER-99150 we've implemented a lock ordering conflict detector.
Similar to SERVER-99703 we have a conflict of an operation holding a lock on the config database proceeding to lock a user database. Other OpObservers like the preimages one take the locks on the opposite order, having a lock on the user database first then proceeding to take a lock on the config database.
As in SERVER-99703 we don't suspect this to be a problem since the locks are intent locks but we still should verify there's nothing of concern
- is fixed by
-
SERVER-99928 Remove lock acquisitions for CSS/DSS read only operations
-
- Closed
-
- related to
-
SERVER-99703 Investigate if we can remove a lock ordering conflict in ShardServerOpObserver
-
- Open
-
-
SERVER-99150 Make threads always acquire locks with strict ordering
-
- Closed
-