-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Internal Code, Querying
-
None
PROBLEM
The server query yielding mechanism uses the saveLockStateAndUnlock/restoreLockState combination of calls in order to get the lock state free all its acquired locks and then re-acquire them.
The re-acquisition of the locks currently must run with UninterruptibleLockGuard because otherwise the interruption exception will unwind to the lock manager's RAII classes destructors and they will try to unlock an already unlocked resource id.
Not being able to interrupt the restoreLockState call though is problematic because it can lead to deadlocks, which would otherwise get resolved automatically.
PROPOSED SOLUTION
I propose making restoreLockState interruptible by introducing an internal variable on the Locker, called boost::optional<LockSnapshot> _yieldedLocks and making saveLockStateAndUnlock place the locks it yielded inside this variable instead of returning them as an output parameter.
restoreLockState will use the values in _yieldedLocks to reacquire the locks back and if it gets interrupted, the Locker::unlock calls can check if a lock was yielded inside the _yieldedLocks list.
- is depended on by
-
SERVER-37244 Implement checkOutSessionForKill API and switch all non-migration callers to use it
- Closed
- is related to
-
SERVER-37711 Revert the `ReplicationStateTransitionLockGuard` functionality
- Closed
- related to
-
SERVER-37682 Do not yield locks in an UninterruptibleLockGuard
- Closed