Uploaded image for project: 'Pentaho Analysis - Mondrian'
  1. Pentaho Analysis - Mondrian
  2. MONDRIAN-1236

Allow schema to be "pinned" in schema cache

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Severity: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None
    • Notice:
      When an issue is open, the "Fix Version/s" field conveys a target, not necessarily a commitment. When an issue is closed, the "Fix Version/s" field conveys the version that the issue was fixed in.

      Description

      Customer has several schemas, each generated using a DynamicSchemaProcessor with client-specific customizations. Cache is usually primed, but they occasionally see big delays. The problem is that garbage collection has thrown the schema out of the schema cache, and therefore the other caches (most notably the cell cache) goes with it.

      Proposed solution is a connect-string parameter telling Mondrian to pin the schema in the cache. While pinned, there is a hard reference to the schema and therefore the schema cannot be GCed, even if there are no active connections.

      If we just specified a "pin=true" parameter, it would do the job, but the cache would fill up unless people were careful. Therefore we intend to implement a "KeepSchemaSeconds=N" parameter. N=0 (default) means don't pin. N<0 means pin forever (use with caution).

      == Design details ==

      The key primitive to implement this would a utility class called ExpiringReference<T>. Similar to WeakReference<T>, except each instance has a time at which it expires. Internally there is a regular reference and a WeakReference. At the expiry time, a timer clears the regular reference, leaving only the weak reference. The class would need a means to increase the expiry time. Even after it has expired, it can be re-instated if the WeakReference still contains a valid pointer.

      There's no point canceling a scheduled firing of the Timer. The TimerTask should fire anyway, but must notice that the expiration time of the ExpiringReference is later than the system time and do nothing.

      Each access to the schema (e.g. creating a connection based on that schema) may push up the expiration time. Note that different clients may have a different value of N. If client 1 accesses at 8am with N=3 hours (i.e. expires at 11am), and client #2 accesses at 9am with N=1 hour (i.e. expires at 10am) then the expiry time remains 11am.

        PractiTest Integration




          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                jhyde Julian Hyde (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: