When using a cache with more than one store, the acquire_lock function has a fairly serious bug: if it fails to obtain a lock of the parent (usually, shared) cache, it still goes ahead and tries to acquire lock locally!

This will cause it to incorrectly report that it acquires a lock.

There can then be failures later because, with the modinfo cache, it checks that a lock has been acquired at both levels. The second level will fail with an error message:

Attempted to set cache key "217398" without a lock. Locking before writes is required for core/coursemodinfo.

Less importantly, if the remote acquire succeeds but the local one fails, it will keep the remote lock. This should not actually happen anyway but the code ought to be robust against it so I will fix that too.

MDL-78467 will reduce the chance for this kind of coding mistake because acquire_lock now throws exception instead of returning a boolean value that you can ignore.

Note: The impact of this bug is relatively low because normally, it is possible to acquire a lock within the timeout. However it can cause confusing errors (as above) if for some reason the lock is not available within timeout.