Caught By Java

Java Caching System (JCS) is a robust open source distributed caching system that is written in Java. It is a subproject of Apache Jakarta project. It provides from basic to advanced level features for caching objects. Since a web application is accessed by many concurrent users that gives you the primary reason to go for object caching. This primary reason gives birth to various other reasons for you to cache objects

1) to reduce the network calls to DB and hence reduce the latency as your application will be dealing with same data most of time in high volume. So instead of fetching same data for every request from DB, cache that data so that next the application will fetch it from the cache instead of making a call to DB.

2) to scale up your application by putting more inexpensive front end servers (storing and replicating the frequently accessed or expensive to create objects in memory) rather than adding expensive and complex back-end database. This reason is not completely related with performance of the application but also the cost of maintaining the application in production.

3) to share same frequently accessed objects so that server heap is utilized efficiently rather than creating similar objects for every request and hogging the heap space. That means caching frequently accessed objects saves expensive CPU time that would otherwise have been spent on re-creating objects again and again for every request.

Prime candidates for caching range from the list data for stable dropdowns, user information, discrete and infrequently changing information, to stable search results that could be sorted in memory.

But remember, object caching does not mean that you cache all frequently accessed data. You have to consider about the available heap size for your application that it would require for its normal business operations that the application has to perform. Just because you want to reduce network call does not mean that you would cache all frequently accessed data. Also it makes no sense to cache rarely accessed objects and take precious memory away from JVM. Your cache should contain only a manageable number of frequently used objects that probably improve the performance of your application unless memory space is not a constraint. We will later discuss this in detail and show how JCS helps you to overcome this memory problem.

There is another interesting point that caching and pooling are two different techniques that caters two different purposes with a common purpose of sharing objects. It is very simple to remember that what to pool and what to cache? Any object that maintains state should be cached and anything that is stateless should be pooled. A book object that maintains a state should be cached.

There are other problems with object caching that you should consider and cater while designing the cache structure for your application.

1) Cache occupies good amount of heap memory in a application server. The application can run out of memory due to not releasing the unused data from the cache at regular intervals.

2) Data Synchronization issues and data inconsistency problem can arise because of inconsistency between stale cached data and original source of data. If original data is updated, cached data should be intimated about the change and update the cached data.

This feature of intimating and updating the cached data comes with a price of putting framework in between the original data and the cached data. And the price is high if it is on a distributed environment. JMS (Java Messaging Service) is one of the examples, can be used to achieve this. Java Caching System provides features that solve the above issues.

JCS provides very simple configuration for setting the caches and auxiliaries. It is very simple to configure, let have a glance on it

 Text | 
 copy code |
?
 
01
# DEFAULT CACHE REGION
02
 
03
jcs.default=DC
04
 
05
jcs.default.cacheattributes=
06
 
07
    org.apache.jcs.engine.CompositeCacheAttributes
08
 
09
jcs.default.cacheattributes.MaxObjects=1000
10
 
11
jcs.default.cacheattributes.MemoryCacheName=
12
 
13
    org.apache.jcs.engine.memory.lru.LRUMemoryCache
14
 
15
jcs.default.cacheattributes.UseMemoryShrinker=true
16
 
17
jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
18
 
19
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
20
 
21
jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
22
 
23
jcs.default.elementattributes.IsEternal=false
24
 
25
jcs.default.elementattributes.MaxLifeSeconds=700
26
 
27
jcs.default.elementattributes.IdleTime=1800
28
 
29
jcs.default.elementattributes.IsSpool=true
30
 
31
jcs.default.elementattributes.IsRemote=true
32
 
33
jcs.default.elementattributes.IsLateral=true

JCS partitions the cache into highly configurable regions. Each region has its own set the configurations apart from default settings that can be overridden. That means each region can be sized differently. Each region can have a different caching algorithm or can be made remote cache servers. Keys defined in one region can be defined in other region as regions are different and do not interfere with each other. JCS defines four types of regions

1) Memory

2) Disk

3) Lateral

4) Remote

A simple example of a region, a cache that contains book objects. Your book cache can be small or large in size depending upon your application requirements. There three categories of settings that can be configured for each region.

1) Element

2) Cache or Region

3) Auxiliary

Auxiliaries provided by JCS helps your application to store cached data into another store like disk or remote server. Suppose that the cache has reached to its maximum object capacity and you want to retain the references, disk auxiliary will spool the least recently used object into the disk to make room for new objects. Likewise you can spool data to a remote server also. JCS also provides failover mechanism using RMI clustering of remote cache servers and keeping serialized versions of objects. There is no need to deploy the class definitions of your cached objects on the remote server as it will never be de-serialized on the remote server. You can control the behaviour of remote cache server by setting the parameter provided by JCS in cache.ccf file. You can also specify the failover server addresses using comma delimiter. In the below example localhost:1101 is treated as a primary server and localhost:1102 is treated as secondary server. If framework fails to retrieve the data from the primary remote cache server it will access the next mentioned secondary remote cache servers.

jcs.auxiliary.RC.attributes.FailoverServers=localhost:1101,localhost:1102

Since JCS provide cache clustering it also provides configuration that allows framework to broadcast updates and removes of cached object so that all remote servers are in sync with each other. You also set parameter GetOnly (Auxiliary Property) to true so that it would cause the remote cache client to stop disseminating updates to the remote server, while continuing to get items from the remote store.

Holding objects in cache requires memory and if these objects are not used for a long time it would be inefficient to hold them as they are wasting an important resource. JCS provides properties through which one can control the behaviour and release objects that are not used for a long time. To invalidate an object in cache, JCS provide three parameters

1) Set the name of the caching algorithm.

2) Set the time to live for an element in a cache.

3) Set the maximum idle time for an element in a cache.

Objects that expire due to exceeding time to live or maximum idle time are cleaned up by ShrinkerThread or will be removed when the cache capacity is reached to maximum. ShrinkerThread is a background thread that runs to check elements in a region that have expired and removes them from the cache.You can also further configure execution interval for ShrinkerThread for each region using parameter ShrinkerIntervalSeconds as per you requirement. ShrinkerThread is only applicable to memory region currently, but you can define the maximum number of keys for other regions.

JCS provides algorithm classes :

1) FIFOMemoryCache

2) LRUMemoryCache

3) MRUMemoryCache

4) ARCMemoryCache

ARCMemoryCache is currently experimental, but will be fully tested soon. It implements an adaptive replace caching algorithm that combines and LRU (Least Recently Used) and an LFU (Least Frequently Used) that adapt to usage patterns.

Java Caching System is highly extensible framework as it is very much configurable through property file (cache.ccf). If have your own proprietary caching algorithm that you want to use with this framework then you need to implement MemoryCache interface and set the property jcs.default.cacheattributes.MemoryCacheName= in # DEFAULT CACHE REGION Section or jcs.region.{your-region-name}.cacheattributes.MemoryCacheName= in # PRE-DEFINED CACHE REGIONS with your class name.

JCS also allows you to log cache events so that you can monitor and audit cache events and good thing is that again you can configure it in cache.ccf and extend by implementing the org.apache.jcs.engine.logging.behavior.ICacheEventLogger interface. Similarly JCS provides event handling for element events.

You can cache any type of data using Java Caching System. Basically one should cache data that does not frequently change and requires a significant amount of time to return from the data source is a good candidate for caching. Cache frequently accessed images that are stored in DB so that less network calls are made. You can cache static report graph images that changes only once in a day. You can cache static data that are required to populate drop down selections.

In next article we will discover more about Java Caching Systems and learn advantages and disadvantages of Java Caching System by comparing it with other caching framework both commercial and open source.