-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Sharding EMEA
-
Fully Compatible
-
Sharding EMEA 2023-02-06
-
151
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Currently in the sharding's op observer when handling sharding's index catalog we're holding collection locks inside the onCommit's handler, this could cause the following behavior: if the OperationContext is interrupted, then attempting to acquire a lock would throw an exception and lead to a server crash because onCommit() handlers are noexcept.
We should move the collection acquiring, like for example, to the sharding index catalog ddl util inside each writeConflictRetry in resource id order.
- is duplicated by
-
SERVER-73184 Ensure collection locks are taken in proper order in the sharding index catalog API
-
- Closed
-
- is related to
-
SERVER-74249 Don't take DB lock in ShardServerOpObserver onCommit handlers
-
- Backlog
-
-
SERVER-74247 Don't take global lock in UserWriteBlockModeOpObserver onCommit handlers
-
- Closed
-