Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[5.4] Cache based Schedule overlap locking #16196
That is the same surely whether you upgrade to 5.3.x or 5.4?
The release process will have a breaking change between them. Or is the issue just because it is a patch version update?
Any reasonable release process on multiple servers will include zero downtime, which would indicate that the release goes live on all servers at the same time, or that servers are taken out of circulation whilst the upgrade is going on, until all servers are upgraded and at the same state.
After the upgrade period have completed, all servers will match, so having the mutex in a file, or in cache shouldn't make any difference, since they'd be using the same checking code.
Any release process on a single server shouldn't matter, since there is only one cronjob to run at any one time anyway, so the mutex is largely meaningless here during the upgrade process.
Or am i misunderstanding the issue?
Wouldn't this be an issue in a
In that case, A fix for that would be that if a cache key isn't found, to check for the lock file. This would make the upgrade process completely BC, and a later patch can remove the lock file, to make it not perform unnecessary actions (Whether 5.5, or 5.4.x)