Caching

This article shows how to implement caching using classes from biz.hammurapi.cache package.

This picture illustrates the primary usage scenario.Producer performs expensive calculations and produces rarely changed object (e.g. produces monthly report). In order to reduce number of calls to the producer Cache is introduced. The cache first looks for an object in itself. If it finds the object by key and entry is not expired it returns it without invoking the producer. If entry is found but expired then produces is invoked to get updated object. The object is placed to the cache and then returned to the client.
Producer can notify cache to discard cached object. This feature is useful in event-driven environment when it is impossible to predict when cached object shall expire.
In case if there is a fallback cache and entry is not found in the main cache then fallback cache is checked for entry and only if there is no entry in the fallback cache the producer is asked for updated object.
Cache interface extends Producer interface and as such you can pipe caches - one cache can be a producer for another. E.g. FileCache can be a producer for MemoryCache if you want all cache entries to survive JVM restart. In a scenario shown above if Cache is MemoryCache and Fallback cache is FileCache then only entries pushed to Fallback cache will survive JVM restart.
There are three cache implementations which are described below.

MemoryCache

biz.hammurapi.cache.MemoryCache class implements memory-sensitive caching using soft references. If fallback cache is not null then items pushed out of memory are placed into the fallback cache.

FileCache

biz.hammurapi.cache.FileCache class is intended to be a fallback cache. It is capable of storing only String keys and serializable values. Non-string keys and non-serializable values are simply discarded.