[SERVER-58222] Investigate op_observer_sharding_impl.cpp lock acquisition Created: 02/Jul/21 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
A new invariant was added where operations that are holding open an oplog hole cannot try to acquire subsequent locks. To temporarily circumvent this check, a new RAII-style class called IgnoreLockConstraintsOnTimestampedTxn was added to opt-out of the invariant. There's a TODO in the codebase for this ticket. See The goal of this ticket should be to determine whether acquiring the lock can actually block in practice (perhaps another thread acquires a stronger lock). |