[SERVER-58223] Investigate shard_server_op_observer.cpp lock acquisitions Created: 02/Jul/21 Updated: 10/Nov/23 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Gregory Wlodarek | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | shardingemea-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||
| Sprint: | Sharding EMEA 2023-10-02, Sharding EMEA 2023-10-16, Sharding EMEA 2023-10-30 | ||||||||
| Participants: | |||||||||
| Story Points: | 2 | ||||||||
| 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). |
| Comments |
| Comment by Kaloian Manassiev [ 02/Jun/22 ] |
|
Moving this to the PM-2144 / EMEA, because it is related to the concurrency control of the DSS. |