Pros and con of JCS (Java caching solution)
JCS is one the popular caching engines used by various developers apart from EHCache, memcached, redis etc. But it has its own merits and demerits. So I will list them all, which I faced while implementing a wrapper over it for my project.
Key Hit/Miss Count
We can see overall statistics of the cache as in how many time was cache hit and how many
times were there misses. But we can not get theses statistics for each key. Suppose you
want to know how many times cache for hit for the key “key1”. EHCache on the other hand
has such granular statistics
No lazy get method
Whenever we call get method, cache statistics will get updated even if we don ‘t want
that. Suppose if you are just checking the existing of get and not really fetching it,
cache hit count will increase by 1.
Last access gets updated
Like previous point even last access of the element gets updated everytime it is accessed
No proper documentation
They have decent documentation on their website for POC kind of application. But if you
want to build a complex caching solution on top of them, you will find it tougher
Not much google help
If you get stuck somewhere there are very less chances that you will get any help from
google. It seems not many people have used JCS
Only one prop file per jvm instance
In JCS we can specify a property files which will have various configuration properties.
In EHCache you can have as many property files and load different cache manager for each
file. But in JCS for each JVM instance you can load only one cache manager
Not able to change diskpath
Though after looking into their internal code I could find a method to override diskpath value at runtime but due to lack of documentation I am not able to use it
JDBC cache keySet method not supported.
Yes for JDBC cache you can not use keyset method and get all the keys in a given cache. Their implementation throws operationnotsupported exception
For JDBC cache key cannot be object.
For simple cache they support object as a key. Even for JDBC they have documented like
that. But if you indert any non-string object as an key, you will get class cast
exception. I checked their code and they have type casted the key into string somewhere.
Not sure, why
String sqlS = “select CACHE_KEY from ” + getJdbcDiskCacheAttributes().getTableName()
438 + ” where REGION = ? and CACHE_KEY = ?”;
440 psSelect = con.prepareStatement( sqlS );
441 psSelect.setString( 1, this.getCacheName() );
442 psSelect.setString( 2, (String) ce.getKey() );
Apart from all basic features expected from a caching engine JCS has following advantages :
Cache distribution is possible. It can be configured either via RMI or external database
No need to install any server. Like EHCache it is a jar only
Like EHCache and unlike Memcached it supports regions. So you can have different regions
with different set of properties
Faster than EHCache
As per their claims they are twice as faster than EHCache for low put and high read applications
Supports multiple types of caches
In memory cache, Disk cache, JDBC cache, Remote cache using RMI
The memory cache is extremely fast. It uses Least Recently Used (LRU) algorithm to manage the objects stored in the memory. The LRU memory cache is based on its own LRU Map implementation. This Map implementation is much faster compared to LRUMap implementation or any other type of Map.