Resin 4.0 jcache (distributed caching)
With Resin 4.0, we can expose our distributed caching/store capabilities to all developers, using the javax.cache interface. Internally, our distributed cache builds on 10 years of work with distributed sessions. So the jcache support isn’t a new capability, really, it’s just newly available for developers.
As an introduction, I want to show the prototypical code sample (it’s an injected Map), and the configuration (one XML tag in the resin-web.xml). The configuration is simple because Resin’s clustered cache is designed for Resin and automatically inherits the cluster and triad configuration from the Resin deployment.
Distributed caching reduces load on the database, improves latency, and can improve reliability by providing a failover capability in a load-balancing configuration. Essentially, you store serialized objects in a Map and the cache makes the Map entries visible across the entire cluster pod automatically.
code samples
In the example below, I’m just storing a fixed string in the cache and retrieving it. Because the cache is distributed, a second request on a different server would return the old data, and skip the processing step.
package example;
import java.io.*;
import javax.servlet.*;
import javax.webbeans.Current;
import javax.cache.Cache;
public class MyServlet extends GenericServlet {
@Current Cache _cache;
public void service(ServletRequest req, ServletResponse res)
{
PrintWriter out = res.getWriter();
String data = (String) _cache.get("my-data");
if (data != null) {
out.println("cached data: " + data);
}
else {
data = generateComplicatedData();
_cache.put("my-data", data);
out.println("new data: " + data);
}
}
}I’m using WebBeans injection to decouple my application code from the configuration. The @javax.webbeans.Current injects the configured Cache as defined in the WEB-INF/resin-web.xml.
configuration
To configure the Cache, I just need to instantiate a ClusterCache instance (in com.caucho.cluster), and give it a name. The name is required and must be unique in the web-app, because the clustered cache needs to manage multiple caches and keep them distinct, but Resin also needs to manage them in a unified way. The unique name avoids any entry conflicts.
<web-app xmlns="http://caucho.com/ns/resin"
xmlns:cluster="urn:java:com.caucho.cluster">
<cluster:ClusterCache name="comment-cache"/>
</web-app>
For specialized uses, the ClusterCache has configuration fields, so you can configure things like the local caching timeouts and expire times, and specify the replication requirements. By default, data is replicated on the triad — a reason why the triad is critical to Resin’s caching.
The ClusterCache can avoid complicated configuration because all the important clustering configuration is already specified in the resin.xml. Because the caching is integrated with Resin’s clustering, the cache handles dynamically added and removed servers. From an administrator’s perspective, it just works automatically.