[SERVER-69461] The behaviour of lock acquisitions differs depending on whether OpContext or Locker is used Created: 06/Sep/22 Updated: 29/Oct/23 Resolved: 27/Sep/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | 7.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kaloian Manassiev | Assignee: | Yujin Kang Park |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2023-06-12, Execution EMEA Team 2023-06-26, Execution EMEA Team 2023-07-10, Execution EMEA Team 2023-07-24, Execution EMEA Team 2023-08-21, Execution EMEA Team 2023-09-04, Execution EMEA Team 2023-09-18, Execution EMEA Team 2023-10-02 | ||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 146 | ||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
There are multiple lock manager RAII classes which take both OperationContext and Locker (or both) and it looks like there exists at least one case where the behaviour of locking differs based on whether locker is passed directly or not. For example, if we remove the Locker-only constructor of ResourceLock, this invariant starts getting hit reliably. The condition to check for the invariant doesn't get reached if opCtx is nullptr (which is what happens if we use the locker-only constructor). Having such differentiation is dangerous and error-prone and we should get rid of it. Architecturally, the OpContext and the Locker are complementary with each other. The OpContext is necessary for the "OS-like" utilities such as interruption, deadline, the operation's settings, transactional state, etc and the Locker is just the container for the currently-acquired locks. |
| Comments |
| Comment by Githook User [ 27/Sep/23 ] |
|
Author: {'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}Message: |
| Comment by Githook User [ 17/Jul/23 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: Revert " This reverts commit fc0cd619e16d8cbdb0a6978cd0f97dcc3f1514ed. |
| Comment by Githook User [ 11/Jul/23 ] |
|
Author: {'name': 'Yu Jin Kang Park', 'email': 'yujin.kang@mongodb.com', 'username': 'ykangpark'}Message: |