Java Cache Tutorial with Cache Dependency Injection (CDI)

From Resin 4.0 Wiki

Faster application performance is possible with Java caching by saving the results of long calculations and reducing database load. The Java caching API is being standardized with jcache. In combination with Java Dependency Injection (CDI), you can use caching in a completely standard fashion in the Resin Application Server. You'll typically want
to look at caching when your application starts slowing down, or your database or other expensive resource starts getting overloaded. Caching is
useful when you want to:

Improve latency

Reduce database load

Reduce CPU use

This example defines a single local, persistent cache named "my-cache", defined in the WEB-INF/resin-web.xml (this part is Resin Application Server specific, of course.) Once the cache is defined, the standard jcache javax.cache.Cache object can be injected into your class with the standard CDI @Inject annotation and used.

Contents

Defining ClusterCache in XML configuration

The definition selected the Resin ClusterCache implementation (you can also use a LocalCache for a single-server cache), gives it a javax.inject.Named name of "my-cache" and configures it. Here we only configure the name, and set the expire time to 1H. (The default is infinite expire.)

CDI inject of javax.cache.Cache

In the MyService class, we inject the cache that we defined using the CDI @Inject and @Named annotations. Normally, CDI recommends that you create custom qualifier annotations instead of using @Named, but to keep the example simple, we're giving it a simple name.

The Cache object can be used somewhat like a java.util.Map. Here we just use the get() and put() methods. Because we set the modified-expire-timeout to be 1H, the get() will return null an hour after the data was populated.

Notice that all the code uses standard APIs without any need to reference Resin classes. Since only the configuration needs to select the Resin cache, your application can easily switch cache implementations.

Cache Performance example

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.

Type

Time

requests per millisecond

Mysql CPU

JDBC

30s

10.0 req/ms

35%

Cache

0.3s

1095 req/ms

0%

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.

Cache Consistency (Updating the Cache)

When your application modifies the data in the database, you will update the Cache as well. If you consistently update the cache each time you
update or delete an entry, you can improve the cache performance and consistency; your data will not be out of date. Using this pattern, your
cache become more of a true storage, rather than a dated snapshot of the data.

The Cache.removeAll() method is typically used when the database is modified outside of the application, for example if you modified
the database directly with SQL.

For the annotation-based configuration, you can use @CacheResult, @CachePut, @CacheRemoveEntry, and @CacheRemoveAll.

Cache Considerations

size: If your data set is large, the cache size can limit how much of your data can fit, resulting in a high miss rate and poor performance. A cache that can page memory out to disk, like

Resin's cache, can allow for large cache sized only limited by your disk space, not your JVM heap space.

persistence: Memory-only caches like memcached are cleared when a server restarts, forcing cache misses until the cache is refilled. With a persistent cache like Resin's cache, a restart loads the most recent data, saving your databases from a big performance spike.

sharding: With a heavily loaded cache, sharding the cache can increase the cache size and performance, by splitting the cache among multiple cache servers. With sharding, exactly one cache

server "owns" a cache entry, reducing conflicts. Resin's cache automatically shards the cache across the three triad hub servers. When Resin's cache has its own cluster, the cache can be sharded across all
the servers in that cache.

consistency: If your cache has multiple "owner" servers, for example in a non-sharded cache, a simultaneous update to two servers can cause a conflict, similar to a synchronization issue. A sharded architecture reduces this problem by allowing only one server to own the entry.

near/local caches: When you have a small number of frequently used and rarely changing objects, a cache can give better performance with an internal local or near cache. Since the shard will

still be the primary owner, it's possible for the local cache to be slightly out-of-date by a configurable time. Writes are always written through to the primary owner.