Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 8.1.0-rc0
Affects Version/s: None
Component/s: None
Labels:
- car-investigation

Assigned Teams:

Catalog and Routing
Backwards Compatibility:
Fully Compatible
Sprint:
CAR Team 2025-03-03
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

In ~~SERVER-99150~~ we've implemented a lock ordering checker. This checker has detected a conflict in the ShardingCatalogManager class.

Inside of this class we have two lock orderings:

Lock the _kClusterCardinalityParameterLock -> Lock the FCV lock due to a setClusterParameter sub-operation
Lock the FCV lock -> Lock the _kClusterCardinalityParameterLock

We should investigate if there's a way to only have one ordering or if the current state is safe considering the FCV lock is taken in shared mode.

related to

SERVER-101435 Complete TODO listed in SERVER-99708

Closed

SERVER-99150 Make threads always acquire locks with strict ordering

Closed

Assignee:: Allison Easton
Reporter:: Jordi Olivares Provencio
Participants:: Allison Easton, Githook User, Jordi Olivares Provencio
Votes:: 0 Vote for this issue
Watchers:: 4 Start watching this issue

Created:: Jan 22 2025 11:33:57 AM UTC
Updated:: Apr 10 2025 08:34:33 PM UTC
Resolved:: Feb 26 2025 04:03:04 PM UTC
Confidence Status Last Update:: 26/Feb/25 12:22 PM