-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
Future Dev
Proposal
Deprecate cachelock plugin type
Background
Cache stores can either implement locking themselves, or rely on cachelock plugins to provide locking functionality when they mapped to a cache that requires locking. Historically, only cachestore_redis has implemented native locking. MDL-67020 added it to cachestore_file.
Rationale
1. Now that cachestore_file supports native locking, all default caches support locking. This works for shared, local and tiered caches.
2. There is only 1 cache lock plugin, cachelock_file. This provides file locking, just like cachestore_file. It seems redundant to support a whole plugin type for one plugin that provides functionality present elsewhere.
3. With cachestore_redis, there are already 2 options for storing caches that require locking.
4. Only one core cache definition (coursemodinfo) actually requires locking.
Options
1. Deprecate cachelock plugins. Remove the cachelock_file plugin itself, and support for non-native locking in the cache API. All caches that require locking will need to be stored on either file or redis caches (or others if they add native locking).
2. Do nothing. Continue to support cachelock plugins.
- will help resolve
-
MDLSITE-6092 One at a time - Policy issues
- Task creation