[SERVER-69462] Lock acquisitions won't always obey the OpContext's deadline or interruption Created: 06/Sep/22  Updated: 11/Jul/23  Resolved: 11/Jul/23

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Yujin Kang Park
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-69461 The behaviour of lock acquisitions di... Closed
Related
related to SERVER-69461 The behaviour of lock acquisitions di... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: Execution EMEA Team 2023-07-24
Participants:

 Description   

There are multiple lock manager RAII classes which take both OperationContext and Locker (or both) in addition to a deadline argument. The behaviour of whether the OpContext's deadline will be obeyed seems dependent on what combination is passed for these three. For example, passing OpCtx=nullptr, Locker, deadline=Date_t::max() will not obey the deadline of the operation, because the OpContext is not passed down to the waiting method of the lock manager.

We have runWithDeadline methods on the OperationContext which will allow us to not have to pass the deadline explicitly.



 Comments   
Comment by Yujin Kang Park [ 11/Jul/23 ]

SERVER-69461 removes the Locker* variants of the RAII constructors, and an OperationContext is always required. So the issue described here is also fixed.

Comment by Haley Connelly [ 06/Sep/22 ]

Linking as related to SERVER-69461 given it refers to the discrepancies between the abstractions of how we use the OperationContext versus Locker

Generated at Thu Feb 08 06:13:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.