Configurable mutex backend.

[rossigee]

OK, so mutex files in a directory somewhere on the web host are great to keep things simple for an average single-host application or local developer environment.

However, in a larger production/clustered/containerised environments, such as we have deployed, we are running 'i18n-hub' containers in a 3-pod deployment for redundancy and load balancing. This means it would create mutex files in the pod filespace of each of the three pods before each pod starts to back off of those requests. Not a big issue, but also not ideal.

My suggestion (well, requirement really) is to make this component more configurable. I suggest to replace the 'file_put_contents' and 'file_get_contents' lines and the '_getMutexPath' method with more generic '_getMutex' and '_setMutex' calls instead, which can then be used to provide a configurable back-end, such as Redis (ideally), that could be used by all three pods to co-ordinate their mutexes.

[rossigee]

Thinking aloud... this would also pave the way for a mySQL-based mutex backend, and we already have a db connection which would be shared between multiple instances. That might be an option for some people who need to co-ordinate the mutex state across machines, but who would prefer not to have to run a shared filesystem or a redis service. IMHO, Redis would still be the best option in our circumstances.

[rossigee]

Another thought, now my gaze has moved on to the CacheAdapter parts of the code, and seeing how that uses PSR6 (good stuff!), and the mutexes are essentially just TTLs, I'm wondering if maybe that's an API that the '_getMutex' and '_setMutex' calls could make use of.