Enable access to Cache Delegates

[FlorianSchaetz]

When using a Cache, especially when using custom Cache implementations, it can be desirable to access that Cache object. Unfortunately, most of the time it will be wrapped into a LoggingCache or similar, which hides this implementation. If would be helpful if LoggingCache, etc. offered a method to get their delegate, so that access to the real Cache instances would be possible. While it is true that direct access to an underlying object might break behaviour of the Cache chain, without such an access, custom Caches will have to be registered into a custom HashMap or similar which tends also be error-prone, especially in a concurrent environment.

[terba]

I would also use this feature on the default cache implementation to access the LoggingCache decorator to get its statistical data. Currently the only accessible statistical value of a cache is its size. Hit ratio is only available in the logs, but I would like to publish that info too on our app's API.

If you are there, please create also public getters for hits, requests and hitRatio attributes as well. Thanks in advance!

[wuwen5]

While it is true that direct access to an underlying object might break behaviour of the Cache chain, without such an access, custom Caches will have to be registered into a custom HashMap or similar which tends also be error-prone, especially in a concurrent environment.

If custom cache can extends from default cache(PerpetualCache), retain the default cache decorators, this is also possible.

like this #818
@harawata Do you agree with this process？if ok, I reopen this

[harawata]

@wuwen5
Hi,
Requiring a custom cache to extend PerpetualCache seems to be a big constraint.
I have just started looking into cache related issues, so please give me some time to figure out a way to achieve what you guys want.

[harawata]

@FlorianSchaetz ,

You wrote...

most of the time it will be wrapped into a LoggingCache or similar

What did you mean by "or similar" here?
I can see a custom cache is wrapped by LoggingCache, but don't see 'similar' cases.

@terba @wuwen5 ,

To log statistics, isn't it better to use the statistics provided by each custom cache implementation like below?

• http://www.ehcache.org/apidocs/2.6.9/net/sf/ehcache/Statistics.html
• http://xetorthio.github.io/jedis/redis/clients/jedis/BinaryJedis.html#info--
• https://github.com/ben-manes/caffeine/wiki/Statistics

If so, just stop wrapping custom caches in LoggingCache could be a solution.

p.s.
By 'custom caches', I meant the external 3rd party cache implementations and not the internal ones.

[terba]

@harawata: I would use that feature with the default (myBatis internal) cache implementation.

[harawata]

@terba Yes, you wrote that in your previous comment. Sorry I had missed it!

I am wondering if it's possible to satisfy @FlorianSchaetz 's request (i.e. accessing external custom cache implementation) without exposing cache delegates.
It wouldn't solve your issue, but one problem at a time. :)

[wuwen5]

Hi @harawata , I have an idea, we can create an abstract cache decorator class.
like this #838, Can you agree this way?

@Test
  public void getSpecifiedDecorator() {
    Cache cache = new PerpetualCache("default");
    cache = new LruCache(cache);
    cache = new LoggingCache(cache);
    cache = new SynchronizedCache(cache);

    cache.putObject("hello", System.currentTimeMillis());
    cache.getObject("hello");

    LoggingCache loggingCache = findCacheDecorator((CacheDecorator)cache, LoggingCache.class);

    assertNotNull(loggingCache);
    assertEquals(1,loggingCache.getHits());

    PerpetualCache cacheDecorator = findCacheDecorator((CacheDecorator) cache, PerpetualCache.class);

    assertNotNull(cacheDecorator);
  }

  private <T> T findCacheDecorator(CacheDecorator cache, Class<T> type) {
    Cache delegate = cache.getDelegate();
    if (delegate.getClass().equals(type)) {
      return (T) delegate;
    } else if (delegate instanceof  CacheDecorator) {
      return findCacheDecorator((CacheDecorator)delegate, type);
    }
    return null;
  }

[wuwen5]

and this eliminates duplicate code for the cache decorator implements.

[harawata]

Hi @wuwen5 ,

Thank you for the PR, but I don't think allowing access to the delegates is a good idea.
For example, SynchronizedCache is useless if your code accesses the underlying delegate.
That is why I am trying to solve this issue ( @FlorianSchaetz 's issue) in a different way.

Regarding @terba 's request, it may be useful to provide basic statistics like hit ratio when using the built-in caches, but providing it via LoggingCache does not seem to be right approach, in my opinion.

[daitangio]

I have similar trouble: I need to get some more stats like max cache size during its life, and I cannot just extend PersistentCache. there is a way to provide a Custom decorator to the CacheBuilder or to extend it a bit?
Also why it is not possible to apply decrators on top of custom caches? I mean...this code inside Cahce Builder

  public Cache build() {
    setDefaultImplementations();
    Cache cache = newBaseCacheInstance(implementation, id);
    setCacheProperties(cache);
    // issue #352, do not apply decorators to custom caches
    if (PerpetualCache.class.equals(cache.getClass())) {
      for (Class<? extends Cache> decorator : decorators) {
        cache = newCacheDecoratorInstance(decorator, cache);
        setCacheProperties(cache);
      }
      cache = setStandardDecorators(cache);
    } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
      cache = new LoggingCache(cache);
    }
    return cache;
  }

cui prodest? why we avoid decorators for custom caches, but we support LoggingCache?

[harawata]

@daitangio
Could you elaborate on your requirements?

• Which cache implementation do you use?
• Which class do you need to access to get the 'stats'?

[daitangio]

For sure. I need a way to access to all the caches to collect stats about their usage (for instance how much % is used and so on).
I need to do maths on these stats.

The only way I find out was to define a custom cache: but doing so I loose all the standard decorators (like LRU + ability to flush them and so on) and it was a disaster :) See "// issue #352, do not apply decorators to custom caches" above.

It could be nice to extend the LoggingCache class if possible or to be able to decorate a custom perpetual cache... OR there is a simple way to access all the PerpetualCache's instances?
Thank you for your prompt response!