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

Policy discussion: Deprecate cachelock plugin type

    XMLWordPrintable

Details

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

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:

                Clockify

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