Cache Component

Last modified by Ecaterina Moraru (Valica) on 2013/11/11 15:12

 Feature
 Completed
 

Description

Existing "frameworks of cache frameworks"

Plexus cache component

Plexus cache component provide api (http://plexus.codehaus.org/plexus-components/plexus-cache/plexus-cache-api/index.html) and some implementations. The problem is that the api is not very generic and the way it is designed you need to know the implementation you use to correctly configure the cache to create. But maybe I take it the wrong way and should not try to force the whole XWiki Platform to be able to use any cache component implementation...

Needs

Normal VS Local cache

We need to be able to implement a cache component supporting only distributed cache and be able to choose one implementation for normal cache (distributed or not) and another for local caches.

Switch implementation

  • the ability to easily switch from one implementation to another in the xwiki.cfg file

Constraints

  • a timed cache. I need this for example to cache macros
  • a cache with a fixed given capacity and expiring the oldest entries (not really sure where we need this right now but it looks common enough)
  • a cache with a fixed given capacity and expiring the least accessed entries (not really sure where we need this right now but it looks common enough)
  • a cache with unlimited capacity and bound only by the memory available. The way to implement this is using PhantomReference.

Basically it's the JVM that calls back the reference to tell it it needs memory. I was told that the new google collections api have some code that do this (I think FinalizablePhantomReference). This cache is the one I would use to save wiki pages' AST in memory.

Design

Current api (see jira issue)

First of all, there is two different component roles :

  • cache : create named cache that can be local or distributed

caches depends on the implementation and its configuration. Typically used for documents cache.

  • local cache : create only and always local caches seems to be

needed by some part of XWiki core like groovy, feed plugin and image plugin That way we can set in the configuration that we want memcached for normal cache and JBossCache for local cache for example.

 

Factory create cache and take parameters like "capacity"

 

Cache object contains :

  • get : get the value by key, can take a timing as parameter

compared to the time the value was registered the last time

  • set : modify or add a value to the cache
  • remove : remove a value from the cache

 

Cache can call listeners on add, delete, update...

 

Cache support generics

This api support all you listed I think (except for the way the timed cache works). It is generally based on the old cache services concepts even all the names changes but the more I'm working with JBoss cache the more I think this api need some changes as JBoss cache and OSCache has very different way to create there caches.

 

Cache configuration overwriting

Code creating a cache can declare an cache configuration identifier which is used to try to find a configuration in a file for example depends on the cache implementation to overload the default settings cache by cache. You can find an example in the image plugin.

Problems/improvements

 

Cache properties

old cache service provide methods taking maps of properties as parameters need by image plugin for example. My problem here is that all existing cache frameworks like OSCache, JBoss etc... are very new to me and I'm not sure of what feature I can generalize in this map. I think of starting by taking all properties setted by image plugin and list them as XWiki Cache properties and translate them for each implementations. Capacity, name all Factory take as parameters should be included in a CacheConfiguration object. Some of theses properties can also be ignored by implementation in some cases. 

Eviction algorithms

I think I need to change the way the timing works in this api as I did not find how to support it in JBoss yet. A more restrictive way and supported by JBoss would be to provided the limit time for the whole cache. I don"t really see a need for more. I'm thinking of introduce eviction algorithms concept like JBoss or cache4j do to replace the way restriction like capacity and timing are supported.

TODO

Meta cache

for documents cache, Ludovic proposed the idea of something like a "meta cache" when we are using distributed cache: the idea is to only store the documents version in the distributed cache and store the reall document in a local cache. The local cache is synchronised with distributed cache based on the documents version:if it changed the document has to be reloaded from the database. This avoid the serialization/unserialization process of the whole document in the distributed cache.

Observation component

See if Observation component contains tools to manage cache listeners.


 


Tags:
    

Get Connected