Description
Following issue #27604 where @nicolas-grekas added the LockRegistry class to prevent cache stampede, and following #27729, I propose that the LockRegistry based cache stampede protection should be optionnaly disableable (without writing code) for various reasons:
- using an NFS shared filesystem, if it is configured aggressively for read velocity, may not always be in sync, making the lock mechanism behaviour potentially variable or inconsistent,
- using an NFS shared filesystem, which syncs correctly, instead of isolating each webhead from each other will in the opposite cause them to have concurrency problems with the locks,
- using a local filesystem for the code (using an immutable docker for example) but a shared file system for the generated cache (actual scenario we did put in place here on some infrastructures) we have an inconsistent locking mechanism: per default,
LockRegistrywill lock on the local isolated filesystem for generating shared files or shared caches, which makes it totally useless in the end, - or just, using a slow filesystem, it will make useless I/O's that in most case, we're trying to get rid of (I take it that replacing it with a remote mutex, it will be slower, but sometime you just want to deactivate the protection).
Moreover, in my past, on many different sites typology we did had to implement mutexes for this exact same scenario: system cache generation (it's the case in Drupal, but we also did it in custom applications cases) but using a remote such as Redis or an SQL database to implement the mutexes. I give it to you, it's slower, but it's also much stronger as soon as you have multiple webheads, since both SQL and Redis are able to provide atomic complex operations, achieving a reliable mutex is quite easy.
The locking mechanism should get out of the GetTrait::get() method and be implemented as a proxy or decorator instead, allowing a much easier configurability or make it much easier to customize or replace stampede protection strategies.