Server caching can speed dynamic pages to near-static speeds. Many pages created by database queries only change every 15 minutes or so, e.g. CNN or Slashdot. Resin can cache the results and serve them like static pages.

By default, pages are not cached. To cache, a page must set a HTTP caching header and be cacheable. Examples of non-cacheable pages include any page using sessions.

Resin's caching operates like a proxy cache. It's controlled by the same HTTP headers as any proxy cache. Every user shares the same cached page.

Setting the Expires header will cache the results until the time expires. For heavily loaded pages, even setting short expires times can significantly improve performance. Sessions should be disabled for caching.

The following example sets expiration for 15 seconds. So the counter should update slowly.
Expires

<%@ page session=false %> <%! int counter; %> <% long now = System.currentTimeMillis(); response.setDateHeader("Expires", now + 15000); %> Count: <%= counter++ %>

Expires is useful for database generated pages which are continuously, but slowly updated. To cache based on something with a known modified date, like a file, you can use If-Modified.

Resin can cache subpages even when the top page can't be cached. Sites allowing user personalization will often design pages with jsp:include subpages. Some subpages are user-specific and can't be cached. Others are common to everybody and can be cached.

Resin treats subpages as independent requests, so they can be cached independent of the top-level page. Try the following, use the first expires counter example as the included page. Create a top-level page that looks like:

<%@ page session=true %> <% if (! session.isNew()) { %> <h1>Welcome back!</h1> <% } %> <jsp:include page="expires.jsp"/>

In many cases, logged in users get specialized pages, but anonymous users all see the same page. In this case, you can still take advantage of Resin's caching, but you'll need to do a little work in your design.

First, you'll need to create an include() subpage that contains the common page. The top page can't be cached because it depends on whether a user is logged in or not.

You must use include() because forward() is cached just like the top page. The top page isn't cacheable because of the user login, so the forwarded page isn't cacheable either.

Here's what a sample subpage might look like:

<%@ page session=false %> <%! int counter; %> <% long now = System.currentTimeMillis(); response.setDateHeader("Expires", now + 15000); String user = request.getParameter("user"); %> User: <%= user %> <%= counter++ %>

The top page slightly trickier because it needs to pass the user to the subpage. You need to pass a unique id. If you pass a boolean logged-in parameter, all logged in users will see the same page.

<%@ page session=true %> <% String user = getSomeSortOfUniqueUserId(); if (user == null) user = "Anonymous"; %> ... <jsp:include page='cachedpage.jsp'/> <jsp:page name='user' value='<%= user %>'/> </jsp:include>

Of course, the top-level page could also be a servlet:

... String user = getSomeSortOfUniqueUserId(request); if (user == null) user = "Anonymous"; RequestDispatcher disp; disp = request.getRequestDispatcher("/cachedpage.jsp?user=" + user); disp.include(request, response);

Resin 1.1 has an experimental anonymous user caching feature. If a user is not logged in, she will get a cached page. If she's logged in, she'll get her own page. This feature will not work if anonymous users are assigned cookies for tracking purposes.

The top page must still set the Expires or If-Modified header, but Resin will take care of deciding if the page is cacheable or not. If the request has any cookies, Resin will not cache it or use the cached page. If it has no cookies, Resin will use the cached page.

User tracking cookies will make the page uncacheable even if the page is the same for all users. Resin chooses to cache or not, based on the existence of any cookies in the request, whether they're used or not.

The If-Modified headers let you cache based on an underlying change date. For example, the page may only change when an underlying source page changes. Resin lets you easily use If-Modified by overriding methods in HttpServlet or in a JSP page.

The following page only changes when the underlying 'test.xml' page changes.

<%@ page session=false %> <%! int counter; public long getLastModified(HttpServletRequest req) { String path = req.getRealPath("test.xml"); return new File(path).lastModified(); } %> Count: <%= counter++ %>

If-Modified pages are useful in combination with the cache-mapping configuration.

cache-mapping assigns a browser Expires to an If-Modified cacheable page. It does not affect Expires cached pages and it does not affect Resin's caching. The FileServlet takes advantage of cache-mapping because it's an If-Modified servlet.

Often, you want a long Expires time for a page to a browser. For example, any gif will not change for 24 hours. That keeps browsers from asking for the same gif every five seconds; that's especially important for tiny formatting gifs. However, as soon as that page or gif changes, you want the change immediately available to any new browser or to a browser using reload.

Here's how you would set the Expires to 24 hours for a gif, based on the default FileServlet.

<web-app id='/'> <cache-mapping url-pattern='*.gif' expires='24h'/> </web-app>

The cache-mapping automatically generates the Expires header. It only works for cacheable pages setting If-Modified or ETag. It will not affect pages explicily setting Expires or non-cacheable pages. So it's safe to create a cache-mapping for *.jsp even if only some are cacheable.