7 Configuring OracleAS Web Cache for the Application

You can use OracleAS Web Cache to improve performance, availability, and scalability of your applications without modifying them. You just have to specify which pages in your applications you want to cache using the Oracle Enterprise Manager 10g Application Server Control Console (Application Server Control Console).

This chapter contains these topics:

Choosing Which Pages to Cache
Analyzing the Application

Note:

This chapter does not cover how OracleAS Web Cache works. To learn about OracleAS Web Cache, see the Oracle Application Server Web Cache Administrator's Guide.

7.1 Choosing Which Pages to Cache

Consider caching the following:

Objects in which the content seldom changes, such as images
Static objects that may be modified occasionally, such as style sheets or PDF
Objects that remain unchanged for a period of time, such as an inventory result
Note:
Use invalidation or expiration to refresh data in the data source when it changes. Otherwise, users may get outdated pages from the cache.

You use the Rules page of Application Server Control Console (Web Cache Home page -> Administration tab -> Properties -> Application -> Rules) to manage cached pages. This applies to static and dynamic elements. To cache a page, you specify the selectors, including the URL expression, to filter through the caching rules to locate the appropriate rule for the request. You then specify instructions for how to act on selector matches. You can use regular expressions to match multiple URLs and to ensure your pattern matches exactly.

The next section shows how the sample application caches static and dynamic pages.

7.2 Analyzing the Application

The only static element in the sample application is a style sheet (blaf.css).

The ID page (Figure 3-1), which prompts the user to enter an employee ID, is a static page in the sense that it does not change over any given period of time, but it is generated dynamically. This is a good page to cache.

The most requested pages in the application are the pages that display employee information. Caching these pages would improve application performance. These pages are dynamically generated, however; the application needs to invalidate them when they are no longer valid.

There are no graphics to cache in this application.

7.2.1 Specifying the Pages to Cache

Figure 7-1 displays the Rules page of Application Server Control Console. The first three rows apply to the sample application.

Figure 7-1 Rules Page in Application Server Control Console

Description of the illustration cachemgr1.gif

Rule 1: Caching the ID Page and the Employee Information Page

The ID page and the pages that display employee information have similar URLs. The URL for the ID page is:

/empbft/controller?action=queryEmployee

The employee information pages have URLs that look something like this:

/empbft/controller;jsessionid=489uhhjjhjkui348fslkj0982k3jlds3?action=queryEmployee&empID=123&submit=Query+Employee

Both URLs have action=queryEmployee. The following regular expression covers both URLs:

^/empbft/controller.*\?.*action=queryEmployee.*

Rule 2: Caching the First Page

The second rule, ^/empbft/$, specifies an optional convenience page that provides a link to the ID page of the application. This page is static. The ^ and $ are special characters used in regular expressions to indicate the beginning and the end of a line. This notation ensures that the pattern matches exactly.

Rule 3: Caching the Style Sheet

To cache the style sheet, specify its URL.

^/empbft/css/blaf.css$

OracleAS Web Cache is populated with default rules during installation. One of the rules, .css, is reserved for style sheets. If your configuration supports this rule, it is not necessary to configure this rule.

Note:

In addition to, or as an alternative to, creating caching rules with Application Server Control Console, application developers can choose to store many of the caching attributes in the Surrogate-Control header of an HTTP response message. This feature enables the application Web server to override the settings configured through Application Server Control Console, as well as allow other third-party caches to use OracleAS Web Cache caching attributes. See the Oracle Application Server Web Cache Administrator's Guide for details.

7.2.2 Invalidating Pages

You need to invalidate dynamic pages in the cache when they are no longer valid. To invalidate cached pages, send an XML file with the URL of the pages that you want to invalidate to the OracleAS Web Cache invalidation port.

The application caches the employee information page, which should be invalidated as soon as the data in the database is updated. One way to do this is to send an invalidation message to OracleAS Web Cache at the end of the add and remove benefit operations. This method, however, does not invalidate the pages when other applications update the underlying tables in the database that the application uses.

A better way is to have the database send the invalidation message when the data in the tables changes. To do this, set up triggers on the tables to fire when data in the tables gets updated. The triggers can call a procedure to send the invalidation message to OracleAS Web Cache.

The procedure that the triggers invoke looks like the following:

-- Usage:
-- SQL> set serveroutput on (When debugging to see dbms_output.put_line's)
-- SQL> exec invalidate_emp('doliu-sun',4001,122);
--
create or replace procedure invalidate_emp (
                            machine in varchar2,
                            port in integer,
                            emp in integer) is
  DQUOTE constant varchar2(1) := chr(34);
  CR constant varchar2(1) := chr(13);
  AMP constant varchar2(1) := chr(38);
  uri varchar2(100) := '/empbft/controller?action=queryEmployee' || AMP ||
                       'amp;empID=' || emp;
BEGIN
  wxvutil.invalidate_reset;
  wxvutil.invalidate_uri(uri, 0, NULL);
  wxvutil.invalidate_exec(machine, port, 'inv-password');
END;

Note:

OracleAS Web Cache provides several mechanisms for invaliding content from external source. In addition, OracleAS Web Cache provides an inline invalidation mechanism for Edge Side Includes (ESI) developers. See the Oracle Application Server Web Cache Administrator's Guide for further details about the available invalidation mechanisms.

7.2.3 Setting up Triggers on the Underlying Tables

The underlying tables in the database have the following triggers. These triggers run the invalidate procedure.

The first trigger is fired when a row is deleted from the EMPLOYEE_BENEFIT_ITEMS table.

CREATE OR REPLACE TRIGGER AFTER_DEL_TRIG
AFTER DELETE on employee_benefit_items
FOR EACH ROW
BEGIN
invalidate_emp('doliu-sun', 4001, :old.EMPLOYEE_ID);
END;

The second trigger is fired when a row is inserted or updated in the EMPLOYEE_BENEFIT_ITEMS table.

CREATE OR REPLACE TRIGGER AFTER_INS_UPD_TRIG
AFTER INSERT OR UPDATE on employee_benefit_items
FOR EACH ROW
BEGIN
invalidate_emp('doliu-sun', 4001, :new.EMPLOYEE_ID);
END;