-
Improvement
-
Resolution: Fixed
-
Minor
-
3.9
-
MOODLE_39_STABLE
-
MOODLE_310_STABLE
-
MDL-67594-master-2 -
-
3
-
Activity Sprint 10, 4.0 holding pattern, 4.0 holding pattern 2
If a lock type supports_recursion() then the locks behave very differently to when they don't.
Yet despite this not a single place in core actually calls for supports_recursion(), and if it did then it would have to do a code fork to work around the different behaviors. This feels like an architectural mistake in the design of the lock api, all lock implementations should behave identically so that calling code doesn't need to worry about things like this.
Given that the only place that leverages this is the unit tests, it is clear no one wants or needs it or is using this. I've had a bit of a quick search on github and in the wild for 3rd party uses and couldn't find any.
It's also trivial to workaround in the lock types that do support recursion to bring their behavior back in line to the locks which don't, as they already internally store a list of open locks for the current request and could just reject the second lock attempt.