Managing Cache Invalidation with OracleAS Portal 10g

An OracleAS Portal Technical Note
June 2004 v0.0.2

| Introduction | Caching Overview | Cache Invalidation Resource Requirements | Scheduling the Soft Invalidation Job | Clearing the Cache Through SQLPLUS |
Clearing the Entire Cache Through the Portal UI | Cache Invalidation and Multiple DADs |

Introduction

This document provides information on the cache invalidation subsystem that will enable Portal Administrators to effectively configure cache invalidation resources to improve performance.

After reading this document the Portal administrator will know how to

• Schedule the soft invalidation job for off-peak times
• Manually clear the entire cache
• Clear the soft invalidation queue
• Clear the entire cache invalidation queue
• Be aware of issues with cache invalidations and multiple DADs

Back to Top

Caching Overview

Oracle Portal makes use of two caching systems - Web Cache, an in-memory cache system, and the mod_plsql file system cache. Web Cache supports invalidation based and expiry based caching. The mod_plsql file system cache supports validation based and
expiry based caching.

Some Portal objects such as pages, some built-in portlets, stylesheets, and public documents are 
cached by Portal. All these types of cached data mentioned can be effectively invalidated except for mod_plsql expiry based cached data.

Portal UI actions such as editing a page, customizing a page, or customizing a portlet may require the invalidation of some cached Portal objects.

Invalidation of cached data stored in Web Cache requires Portal to open a TCP/IP connection with the Web Cache invalidation port in order to send XML invalidation messages. There is no restriction on the type of data stored in Web Cache that can be invalidated.

Invalidation of validation based cached data stored in the mod_plsql file system cache causes Portal to update a validation "ping check" value in the database, typically a timestamp. This will cause the validation "ping check" that is performed by mod_plsql to fail the next time the data is requested  so that new data is generated by Portal.

Cache invalidations can be classified into two groups - "hard" and "soft". Hard invalidations are queued up over the duration of a single browser request and are then executed together when the Portal UI action completes. The results will be seen immediately. Most page edits and all portlet customizations are treated as hard invalidations. Soft invalidations are queued up over possibly many browser requests and are then executed later on by the soft invalidation database job. This job runs periodically and can be configured by running the script $ORACLE_HOME/sso/admin/plsql/wwc/cachjsub.sql. Security related changes, eg. granting privileges on a page to a user or group, are treated as soft invalidations.

Back to Top

Cache Invalidation Resource Requirements

Large numbers of invalidations may slow the system down for the following reasons:

• Communication with Web Cache
  
  When either hard or soft invalidations are processed a TCP/IP connection must be established with the Web Cache invalidation port in order to send invalidation messages to Web Cache.
  
  For hard invalidations, all the messages queued in one browser request are sent via one TCP/IP connection to Web Cache.
  
  For soft invalidations, all the messages processed by the soft invalidation job are sent via one TCP/IP connection to Web Cache.
  
  Web Cache receives these invalidation messages and attempts to invalidate cached data. This load may affect Web Cache's ability to respond to requests for data.
  
• Cache invalidation queue storage
  
  Both hard and soft invalidation messages are queued up into a database table in the Portal repository. As the queue grows in size more database resources are required to maintain the queue.
  
• Cache invalidation queue optimization
  
  During the processing of hard or soft invalidation messages, queue optimization takes place in order to remove duplicate or unnecessary invalidation messages, eg. if a page group is being invalidated then individual invalidation messages for pages
  in the page group are unnecessary.
  
  If a large number of invalidation messages have been queued up then the optimization process may take a long time.

Back to Top

Scheduling the Soft Invalidation Job

Hard invalidations are always executed immediately after the browser request that initiated them. However, soft invalidations are queued up and then processed by the soft invalidation job the next time it runs.

Note that the soft invalidation job should never be disabled indefinitely. Doing this will cause soft invalidations to be queued up but never processed and removed.

The script $ORACLE_HOME/sso/admin/plsql/wwc/cachjsub.sql can be in SQL*PLUS to schedule the background job to run periodically in one of the two following ways:

1. cachjsub.sql 'START' '' 60

   This method of executing cachjsub.sql to configure the soft invalidation indicates that the job will run immediately and run again every 60 minutes. The value '60' can be replaced with another number if a different period is required. 
   

2. cachjsub.sql '18:00' 'hh24:mi' 360

   This method of executing cachjsub.sql to configure the soft invalidation indicates that the job will be run at 18:00 which is interpreted as a date using the date format 'hh24:mi'. The job will run every 360 minutes after the initial run.
   
   The cachjsub.sql script can be used to schedule soft invalidation processing to run during off-peak times.
   
   For example, if the Portal administrator knows that there will be heavy use of the Portal from 10 AM to 2 PM then the soft invalidation job can be scheduled to avoid executing during this time as follows

   cachjsub.sql '09:00' 'hh24:mi' 360

   This will cause the soft invalidation job to commence at 9 AM and run every 6 hours afterwards. This means that during the peak load time of 10 AM to 2 PM the soft invalidation job will not execute. 

Back to Top

Clearing the Cache Invalidation Queue Through SQL*PLUS

Sometimes the cache invalidation queue may grow excessively large as a result of user actions. 

For example, repeated granting of security privileges on a page to a group with a large number of members will place one soft invalidation in the queue per user per grant.

Some soft invalidations may not be necessary but the Portal may not be able to determine this. For example, if a group's privileges on a page were upgraded from 'View' to 'Fully Customize' but no member of the group had yet viewed the page then no invalidation is necessary. However, Portal does not have a record of who has viewed the page so therefore the only choice is to proceed with the soft invalidation associated with the security change.

The Portal administrator can check the number of soft invalidations in the queue by executing the following query in SQL*PLUS as the Portal schema owner

select count(1) from wwutl_cache_inval_msg$ where process_type=2;

The Portal administrator can check the total number of invalidations, hard or soft, in the queue by executing the following query in SQL*PLUS as the Portal schema owner

select count(1) from wwutl_cache_inval_msg$;

The number of rows in the table wwutl_cache_inval_msg$ that can be considered excessive depends to some extent on the speed of the infrastructure running the database. However, typically 50 000 messages will cause the soft invalidation job to take a long time to process and sending 50 000 invalidation messages to Web Cache will introduce network load as Portal communicates with the Web Cache invalidation port.

If the soft invalidations are known to be unnecessary then the Portal administrator can perform the following query in SQL*PLUS as the Portal schema owner

delete from wwutl_cache_inval_msg$ where process_type=2;

This removes soft invalidations from the queue.

If the soft invalidations are necessary but there is an excessively large number then the Portal administrator can clear the cache invalidation queue using the following command:

truncate table  wwutl_cache_inval_msg$;

The Portal administrator should then clear the entire cache through the Portal UI as described in the next section.

 to Top

Clearing the Entire Cache Through the Portal UI

The Portal administrator may sometimes want to clear all cached Portal data. This is done as follows:

1. Navigate to the Portal Builder Administer tab.
2. Select the Global Settings link.
3. Select the Cache tab.
4. Select the 'Clear The Entire Web Cache' checkbox.
5. Press Apply or OK.

This performs a hard invalidation so that the cache is cleared immediately.

Back to Top

Cache Invalidation and Multiple DADs

Oracle Portal 9.0.2 and later support invalidation of data cached in Web Cache on a DAD by DAD basis for a given Portal instance. 

Invalidation messages sent to Web Cache require that the DAD information be included. The reason is that data cached in Web Cache uses the URL as one of the cache lookup keys and the URLs used to access Portal data contain the DAD name. Therefore the DAD name must be included explicitly in the invalidation message. 

The use of multiple DADs to access a single Portal instance is strongly discouraged since there is no compelling reason to have such a configuration.

Note that if Web Cache is removed from the Portal configuration then multiple DADs may be used to access a single Portal instance since cache invalidations of the mod_plsql file system cache, i.e. updates of the ping check data stored in the database tables, do not make use of DAD information. However, without Web Cache, system performance is affected adversely.

Back to Top