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 :

Distributed cache

Cache distribution is possible. It can be configured either via RMI or external database

Easy Installation

No need to install any server. Like EHCache it is a jar only

Supports Region

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

Fast Map

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.

Uday Ogra

Connect with me at and lets have some healthy discussion :)

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *