Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Open source Java projects: Java Caching System

A distributed caching system for enterprise applications

By Steven Haines, JavaWorld.com, 11/13/08

Page 2 of 5

If your application has a manageable number of objects that are frequently accessed, then a cache can probably improve its performance. Java applications are constrained by available resources in the JVM, the most precious of which is memory. It makes no sense to take memory away from a JVM to hold objects that are rarely accessed. It's probably better to load an object that's accessed once every few hours as it's needed and leave enough free memory for other resources. On the other hand, it's better to load objects that are accessed several times a minute -- or even several times an hour -- into a cache and serve them from memory, rather than make a remote call every time the object is needed. If the number of objects your application accesses frequently is manageable within the available memory, then it is a good candidate for caching. But if it accesses millions of objects frequently, then it still might be in an application's best interest to load objects as needed rather than use 75 percent of a JVM's heap to host the cache.

Caching versus pooling

Confusion about the distinction between a cache and a pool often emerges in discussions about caching. Which objects should be cached and what objects should be pooled? The answer lies in the nature of the objects themselves. If an object maintains state, it should be cached. Stateless objects should be pooled. As an analogy, consider two activities: buying food at a supermarket and picking a child up from school. Any cashier can check out any customer at the supermarket; it doesn't matter which cashier you get, so cashiers should be pooled. When you pick up your child from school, you want your child, not someone else's, so children should be cached.

Extrapolating this idea out to enterprise Java, resources such as database connections and business processing beans should be pooled, whereas objects such as employees, documents, and widgets should be cached. It doesn't matter which database connection your application obtains from a connection pool -- they all do the same thing -- but if you want to give yourself a pay raise, it is important that you obtain your employee object.

Understanding JCS regions

Using JCS is actually quite simple, but you need some foundational knowledge about how JCS defines cache regions and how they can be configured. The JCS properties file is the logical place to start understanding JCS. Listing 1 shows a sample JCS properties file.

Listing 1. A JCS properties file (cache.ccf)

# DEFAULT CACHE REGION
jcs.default=DC
jcs.default.cacheattributes=
     org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=1000
jcs.default.cacheattributes.MemoryCacheName=
     org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.default.cacheattributes.UseMemoryShrinker=true
jcs.default.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.default.cacheattributes.ShrinkerIntervalSeconds=60
jcs.default.elementattributes=org.apache.jcs.engine.ElementAttributes
jcs.default.elementattributes.IsEternal=false
jcs.default.elementattributes.MaxLifeSeconds=21600
jcs.default.elementattributes.IdleTime=1800
jcs.default.elementattributes.IsSpool=true
jcs.default.elementattributes.IsRemote=true
jcs.default.elementattributes.IsLateral=true

# PREDEFINED CACHE REGIONS
jcs.region.musicCache=DC
jcs.region.musicCache.cacheattributes=
     org.apache.jcs.engine.CompositeCacheAttributes
jcs.region.musicCache.cacheattributes.MaxObjects=1000
jcs.region.musicCache.cacheattributes.MemoryCacheName=
     org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.musicCache.cacheattributes.UseMemoryShrinker=true
jcs.region.musicCache.cacheattributes.MaxMemoryIdleTimeSeconds=3600
jcs.region.musicCache.cacheattributes.ShrinkerIntervalSeconds=60
jcs.region.musicCache.cacheattributes.MaxSpoolPerRun=500
jcs.region.musicCache.elementattributes=
     org.apache.jcs.engine.ElementAttributes
jcs.region.musicCache.elementattributes.IsEternal=false

# AVAILABLE AUXILIARY CACHES
jcs.auxiliary.DC=
     org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC.attributes=
     org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC.attributes.DiskPath=c:/temp
jcs.auxiliary.DC.attributes.MaxPurgatorySize=10000000
jcs.auxiliary.DC.attributes.MaxKeySize=1000000
jcs.auxiliary.DC.attributes.MaxRecycleBinSize=5000
jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount=300000
jcs.auxiliary.DC.attributes.ShutdownSpoolTimeLimit=60

Listing 1 contains three sections: