Page 2 of 2   « previous page

The main goal in constructing cache ID generation rules is to specify what is different and what is "identical" for caching purposes (and what should not be cached at all). Please make sure you do not lump together requests that call for different responses. Otherwise your application's functionality is compromised, which is unacceptable. On the other hand, the very goal of caching is reuse and the measure of caching success is in the cache hit ratio, the share of requests that are satisfied from cache. If you mistakenly separate requests that are in fact equivalent (producing the same responses), caching efficiency will be reduced, although application functionality will be preserved.

Differentiators
So the most important part of reuse rules is specifying the differentiators - something that helps the server differentiate responses, and identify equivalent responses. If you had no differentiators at all, your design choices would be severely limited - too limited for real life. What can be a differentiator? Fortunately, a lot of things can, so you have a good menu of design choices. Here are the cache ID differentiators:

• Parameter-value of any named parameter from HTTP request
• Parameter-list-list of values for named multiple-value HTTP request parameters
• Session-named value from HTTP session
• Cookie-named cookie value
• Attribute-named request attribute
• Header-named HTTP request header (e.g. Accepts, User-Agent)
• pathInfo and servletPath-fragments of URI
• User's locale
• requestType-HTTP method (e.g. GET, POST)

And if your real-life situation still cannot be described by using all of the above facilities, you have an option of supplying a completely custom solution by writing your own cache Id generator class. In vast majority of cases, you will only need to implement a single method called "getId", which will be invoked by the server once for each requested page. This method receives an instance of ServletCacheRequest, a subinterface of HttpServletRequest. Through this interface you have full access to Http request, Http session and a few additional cache-related attributes. With the full power of Java at hand you may be as fancy with cache id generation as you'd like.

Listing 3 contains a simple version of cachespec.xml for our catalog application.

Early to Rise...
By now it's easy to see that in order to fully harness the power of Dynamic Cache, you must start thinking about it early in your project. There are several reasons why it is usually difficult or even impossible to incorporate Dynamic Cache when you are far into the construction phase. The first reason deals with using mosaic pattern. Suppose you have your application fully coded and now want to take advantage of Dynamic Cache Service by applying mosaic patterns. You have identified parts of HTML pages that can be reused if they were made independent JSPs. But in the real world you simply can not rip out a part of a working JSP, save it away in another file you include in the master JSP and expect the whole thing to keep working.

The task becomes monumentally difficult if Model-View-Controller pattern is used, such as ubiquitous Struts or Java Server Faces. In MVC, all heavy lifting is done beforehand. JSP enters stage at the last moment and simply presents output in appropriate format, usually HTML. This means mere reshuffling your JSPs will not yield performance gains as amount of preparation work does not change. Your changes will need to cut deeper into Controller logic. You would have to restructure your MVC Controller and rewrite quite a bit of Java code (e.g. Actions and Forms) in order to employ Mosaic pattern effectively. This is just too much work and too much risk to undertake late into a project. But even if your application is totally JSP-driven, there are dependencies, such as local variables, custom tags and imports, that make this task non-trivial. Once your page structure is in place, it will be difficult and risky to attempt wholesale page refactoring.

Another reason to keep Dynamic Cache on your mind early in the project is based on user aggregation needs. Suppose you identify a way to aggregate your user community into several user groups. Or you found that a certain Intranet application page looks the same for all users from the Chicago office. Now you need to translate your knowledge into cache ID generation rules. But do you have all the necessary information available and easily accessible for the cache ID generator? You may be lucky and already have it in place. Or you may find yourself out of luck because the "user group" or "office ID" attribute, while used somewhere in the business logic layer, is not delivered to the presentation layer of your application. If you had Dynamic Cache in mind earlier, you could've simply added "user group" to the Http Session or came up with another elegant mechanism. By delaying consideration of caching, you might needlessly miss an opportunity to improve performance.

When you first create templates for JSPs, you must account for separation of reusable (but not static) common fragments, such as menus and navigation bars. In our catalog example, you should realize that ProductCatalog.jsp is a good candidate for splitting out of a loop body into a separate ProductCatalogEntry.jsp. Throughout Java design, you may want to identify your cache ID differentiators and make them easily accessible to the caching engine.

Don't miss your opportunities -be on a lookout for ways to improve application performance from early stages of your development project and take advantage of the performance gains available with Dynamic Cache Service.

Page 2 of 2   « previous page