Revision as of 00:00, 28 January 2012

Java caching can speed application performance and lower database load by annotating cacheable methods. The Java caching API (JCache) includes standard method annotations that let you add caching just by annotating your methods. Assuming your bean is a Java Dependency Injection (CDI) bean, your method will be cached automatically. When using an application server like the Resin application server that supports both CDI and JCache, you can add caching easily without much configuration.

@CacheResult is the base annotation for method-based Java caching, and the heart of this tutorial. It uses the method parameters as a cache key, and stores the method result in the cache. On the next method call, the enhanced method will look for the saved result in the cache, and return it, saving the effort of the method.

You'll want to cache to

• Improve latency
• Reduce database load
• Reduce CPU use

If you want to see how to use the javax.cache.Cache directly, you can look at the Java Cache Tutorial for an example.

@CacheResult Example

With the caching annotations, you can add caching with the following two steps:

1. Add a @CacheResult annotation to the method you want to cache
2. Use Java Dependency Injection (CDI) to get the bean

In the example, we'll inject the MyBean into a servlet for testing using the CDI @Inject method.

Using @CacheResult with the action bean

MyBean.java

 package org.example.mypkg;

 public class MyBean {
   @CacheResult
   public String doLongOperation(String key)
   {
     ...
   }
 }

Using CDI @Inject in a Servlet

MyServlet.java

 package org.example.mypkg;

 public class MyServlet extends GenericServlet {
   @Inject MyBean _bean;

   public void service(ServletRequest req, ServletResponse res)
     throws IOException, ServletException
   {
     PrintWriter out = res.getWriter();
 
     String result = _bean.doLongOperation("test");
  
     out.println("test: " + result);
   }
 }

Enabling CDI Scanning

WEB-INF/beans.xml

 <beans/>

Performance Benefits of Caching

Since reducing database load is a typical cache benefit, it's useful to create a micro-benchmark to see how a cache can help. This is just a simple test with mysql running on the same server and a trivial query. In other words, it's not trying to exaggerate the value of the cache, because almost any real cache use will have a longer "doLongCalculation" than this simple example, and therefore the cache will benefit even more.

The micro-benchmark has a simple jdbc query in the "doLongCalculation" method

"SELECT value FROM test WHERE id=?"

and then to get useful data, the call to "doStuff" is repeated 300k times and compared with the direct call to "doLongCalculation" 300k times.

Even this simple test shows how caches can win. In this simple benchmark, the performance is significantly faster and saves the database load.

• 10x faster
• Remove Mysql load

To get more realistic numbers, you'll need to benchmark the difference on a full application. Micro-benchmarks like this are useful to explain concepts, but real benchmarks require testing against your own application, in combination with profiling. For example, Resin's simple profiling capabilities in the /resin-admin or with the pdf-report can get you quick and simple data in your application performance.

The Resin ClusterCache implementation

Since Resin's ClusterCache is a persistent cache, the entries you save will be stored to disk and recovered. This means you can store lots of data in the cache without worrying about running out of memory. (LocalCache is also a persistent cache.) If the memory becomes full, Resin will use the cache entries that are on disk. For performance, commonly-used items will remain in memory.