[SERVER-77424] Use a unique Locker for every ShardingDDLCoordinator Created: 24/May/23 Updated: 29/Oct/23 Resolved: 20/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Silvia Surroca | Assignee: | Silvia Surroca |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding EMEA 2023-06-12, Sharding EMEA 2023-06-26 | ||||||||
| Participants: | |||||||||
| Description |
|
On one side, the ShardingDDLCoordinator is creating and destroying several OperationContext objects since it uses a task chain to perform its operations. On the other side, the lock state is bound to an OperationContext through a Locker object, and that Locker object is created and destructed together with the OperationContext. However, the new DDLLockManager implementation requires keeping a Locker object alive and attached to a ShardingDDLCoordinator in order to hold DDL locks across a task chain. The aim of this ticket is to keep a unique Locker object per ShardingDDLCoordinator by attaching and detaching it to the current OperationContext once its constructed and destructed respectively.
|
| Comments |
| Comment by Silvia Surroca [ 20/Jun/23 ] |
|
Committed under |