Cache « Development « Java Articles

Now that we have covered the basics of how caching works, let's look at some of the well-known scenarios in a J2EE application that use object storage mechanisms similar to caching.

In this article, I discuss a common structural problem for client applications: they wind up either making an excessive number of remote method calls to a naming service or implementing some form of local cache for the naming service. After outlining the problem, I'll show you how to extend the command object framework, introduced in the first article, to provide seamless caching of stubs. Using these new extensions will make your RMI code simpler and more robust.

Recently, in the web portal application I have been working on, we had a requirement to store some lookup data (such as rate revision data, state and product lists) in the memory of a servlet container (Tomcat) so we wouldn't hit the back-end database every time we access the data. At the same time, we needed to refresh the data stored in the memory at predefined time intervals so it didn't become stale and inaccurate. We also needed a mechanism to refresh different types of data stored in the memory at different time intervals. For example, rate revision data had to be refreshed once every day, whereas the lookup data could stay in the memory for longer periods of time. Object caching was the perfect solution to accomplish all of these tasks in one shot.

POJO caching is the best place to start to learn how OSCache works. All the other types of caching build upon this API to provide some particular feature. Caching plain old java objects is the most flexible but it will not perform as well as other forms of caching that intercept request processing earlier. For example, POJO caching is not tied to any particular view technology; however, it does not eliminate any of the costly view processing that is alleviated by the HTTP response and JSP tag caches. I recommend using one of the specific cache implementations, if one exists.

This leads to a problem as it's unlikely that both the threads servicing requests and the update thread will be able to use your cache simultaeneously. You may be tempted to use an exclusive lock such as a Java synchronised block to handle this. This will work but it is probably the worst way that you can do this from a performance perspective. This articles shows how you can use reader writer locks to accomplish the same thing using a much more efficient technique.

Often in talks we give examples of common aspects, such as caching, pooling, auditing, security, persistence, and so on. I thought I'd start a mini-series of blog entries that examine some of these common aspects in turn and show you how to implement them using AspectJ. In Parts 1 and 2 I'm going to look at caching.

Many Web applications are being rewritten from desktop applications; ideally, they should be as fast and scalable as the desktop versions. Almost all Web applications could benefit from a substantial increase in speed. Caching of frequently viewed data that changes infrequently is a powerful way to decrease wait time for users. A utility that easily handles the caching of data with a simple, nonintrusive API can help you accomplish this goal. The open source JCS, an Apache Jakarta project, is one such tool. This article explains how to configure and use JCS to cache data for your Web applications.

There is no mention of SwarmCache getting plugged into any of the popular ORM tools. Hence, it is assumed that caching in the data access layer needs to be done specifically using SwarmCache's API.