Cache engine

The Cache engine is responsible for Caching rules either in memory or in a physical storage, typically a key-value store. Currently the following caches are supported:

• Session Cache
• Moneta Cache

The Session cache wraps a simple HashCache and stores the rules in the session so it is available between requests in the web app. This is the fastest rules cache. However always be careful not to store too much data in the session! Also consider using a different session store than the default cookie storage which is very limited.

The Moneta cache can be configured for various types of key-value data stores.

Cache engine configuration

The rules cache needs a store to store the rules. Cantango is setup to use a Session store by default. The session store is internally setup to wrap a Moneta memory store.

To configure the cache store for the rules cache:

Cantango.configure do |config|
  config.cache.store do |store|
    store.default Cantango::Cache::MonetaCache
    store.default_type :redis
    store.options = {:port => 5032}
  end
end

Alternatively you can define your own Cache store factory:

Cantango.configure do |config|
  config.cache.store do |store|
    store.factory Proc.new {|name, options| MyFantasticCache.new name, {:awesome_power => true}.merge(options) }
  end
end

Caching logic

The Ability #initialize method receives a candidate and an options hash.

If caching is enabled, caching proceeds as follows:

1. Cache key is generated for the candidate
2. Rules are generated
3. Rules are stored in the Caching store with a cache key for the candidate
4. In subsequent requests rules are retrieved from the cache for the same cache key

Note: Recently the Caching logic has changed substantially and is now much more advanced and fine-grained. The new caching logic (and caching key logic) will be documented ASAP.

Cache key

A cache key is generated for the candidate in order to ensure that the rules are cached for that exact candidate and not reused for another candidate. The cache key is generated from a unique identifier of the candidate, and the list of roles and role groups. If the candidate changes any of these, a new cache key will result and thus likely no cache hit for that key.