Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-76086

Policy discussion: Deprecate cachelock plugin type

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Future Dev
    • Policy

      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.

            Unassigned Unassigned
            marxjohnson Mark Johnson
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.