Portal pages are not defined as static HTML files—they are generated from content that is either stored in a database or retrieved from a Web provider. Dynamically assembling a page from multiple sources can be a very expensive operation, in terms of both CPU consumption and network latency. Therefore Oracle9iAS Portal uses sophisticated caching mechanisms to minimize database and provider calls. Page metadata, portlet content, and rendered pages are all cached to achieve a high degree of scalability and performance while still enabling dynamic personalization and protecting the security of portal content.
This topic is divided into the following sections:
| Caching types | User and system level caching | Page caching | Portlet caching | Document and image caching | Event caching | Login metadata caching |
Three types of caching are used for portal content:
Invalidation-based caching uses Oracle9iAS Web Cache to cache content. When various events occur that require that content in the cache be refreshed, the portal or providers send invalidation messages to Web Cache. When an entry in Web Cache is invalidated, it will be refreshed the next time it is requested. Web Cache entries are also invalidated when their time in the cache exceeds the Maximum Expiry Time global setting.
For more information about Web Cache, refer to the Oracle9iAS Web Cache documentation.
Validation-based caching uses the Portal Cache to cache content. Before an entry in the Portal Cache is used, the Parallel Page Engine or mod_plsql contacts portal or a provider to validate that the cache entry is still valid.
Expiry-based caching also uses the Portal Cache to cache content. Expiry-based cache entries use an expiry period to specify the length of time they are valid, known as the cache retention period.
Note: Pages that use expiry-based caching may also be cached in users' browsers.
Validation-based and invalidation-based caching both ensure that users are seeing the most up-to-date information. These types of caching are most appropriate for content that can change frequently or on a random basis and for which the cost of the validity check or sending the invalidation message is low. For example, a document can be quickly checked for changes by comparing time-stamps between the cache and the portal.
Expiry-based caching, on the other hand, pins a cache entry to the cache for a specified period of time. Expiry-based caching can result in better performance, since certain checks and refresh operations are eliminated; however, users may be seeing stale content if the underlying data changes before the expiry-based cache entry expires. Expiry-based caching is most appropriate when content is not time-sensitive and the cost of validating or invalidating the content is high. For example, use expiry-based caching where an expensive query is required to see if a new product has been added to a catalog, yet the catalog is updated infrequently and users don't need to see the updated immediately.
Oracle9iAS Portal supports user customizations of pages and portlets. It also filters out portlets and content items that a user is not authorized to view. Because of these customizations and security features, the view of a page can vary from one user to the next. Portal's caching is designed to allow content to vary on a per-user basis, even though the physical URL being cached is the same across users.
A portlet developer can specify either of two levels of caching for a portlet:
System level caching allows users to share a single cache entry. System level caching requires that an object be accessible by all users (i.e., the object does not enforce access privileges) and is not customizable. A big advantage to specifying system level caching for an object is that a single copy of the object can be cached and shared by all users. Examples of content that are suitable for system level caching include page banners and news portlets.
User level caching is for a specific user—the cache entries stored are unique for that user only. User level caching must be used for objects that can be customized or that enforce their own access privileges. For security reasons, Web Cache caches user level entries on a per-session basis only (session level caching); when a user logs out, his or her Web Cache entries are no longer accessible. User level Portal Cache entries, which are accessed only through the Parallel Page Engine, are protected from unauthorized access and can therefore be shared across multiple sessions for the same user. For example, if a user logs out of Portal and then returns the next day, he or she will use valid cache entries from the previous day's session that are still stored in the Portal Cache.
Note: Web portlets can be cached at the system, user, and session levels. Database portlets can be cached at the system and user levels only.
Pages (including both the page definition and the assembled page) are always cached at the user level. Page definitions in Web Cache are cached on a per-session basis. When a session ends (i.e., when the user logs out or closes his or her browser), the Web Cache entry is no longer accessible. However, the next time the user logs in, the Web Cache entry can be recreated from the cached user level page definition in the Portal Cache.
Page caching works identically for normal pages and for Java Server Pages that have been loaded into the portal (internal JSPs). The portal caching mechanisms do not cache external JSPs—JSPs that contain portlets but that run externally to the portal; however, caching is managed by the portal for the portlets contained on external JSPs. For more information about JSPs, see Working with Java Server Pages.
The following table summarizes the recommended page caching options for different types of content:
Content |
Recommended page caching option |
|
Static (e.g., items that are manually updated). |
Cache page definition and content with a long retention period. Changes to the page definition (including modifications to items) will force a refresh, even if the page has not expired. |
|
Portlets with expiry-based caching. |
Cache page definition and content. Retention period should be less than or equal to the shortest portlet retention period. |
|
Portlets with invalidation- or validation-based caching where some stale content is acceptable. |
Cache page definition and content with a short retention period. |
|
Portlets with invalidation- or validation-based caching where content must always be up-to-date. |
Cache page definition only to ensure that portlet validity is checked when the page is assembled. |
|
Dynamic items (PL/SQL, URL) where some stale content is acceptable. |
Cache page definition and content with a short retention period. |
|
Dynamic items where content must always be up-to-date. |
Don't cache. It's a good idea to put this content on pages that are not frequently accessed, or use portlets instead of items and choose Cache page definition only. |
Like pages, portlets can use invalidation-based, validation-based, or expiry-based caching. Database portlets can also use a combination of invalidation- and validation-based caching. All types of caching function the same as for pages, with the following differences:
With all types of caching, the portlet content is cached, not the portlet metadata. This means that only the rendered view of the portlet is cached, not any metadata that is used to generate or personalize the portlet.
When expiry-based caching is used for a portlet, the provider is not contacted until the cache entry expires (pages are always validated, even if the page cache entry has not expired).
The portlet developer specifies the type of caching that is used through the APIs of the Portal Developer Kit (PDK), which can be found on Oracle Technology Network. The following table summarizes the recommended portlet caching options for different types of content:
Content |
Recommended portlet caching option |
|
Static, infrequently updated, shared by all users (e.g., page banner, or company tombstone data like mission statements and office locations). |
Expiry-based with long retention period. System level. |
|
Static, periodically updated, shared by all users (e.g., company news bulletins). |
Expiry-based with short retention period (depending on update frequency). System level. |
|
Static, periodically updated, personalized (e.g., list of Favorite Web sites, customizable by users). |
Invalidation-based, or combined invalidation- and validation-based. User level. |
|
Dynamic (generated from database), does not require real-time updates, shared by all users (e.g., product catalog). |
Expiry-based. System level. Choose retention period to meet business requirements for timeliness. |
|
Dynamic, personalized, does not require real-time updates (e.g., delayed stock quotes). |
Expiry-based with short retention period. User level. |
|
Dynamic, personalized, requires real-time updates (e.g., active trouble tickets in a helpdesk portlet, real-time stock quotes). |
Don't cache or use combined validation- and invalidation-based if the application can trigger an invalidation message. User level. |
Use invalidation-based caching instead of expiry-based caching if your application can be modified to send invalidation messages to Web Cache when content needs to be refreshed, or if the user can manually refresh the content (e.g., by clicking a Refresh link in the portlet).
If appropriate, try to combine invalidation-based with validation-based caching (the combination is currently available for database portlets only). When these options are combined, a session based Web Cache entry can be refreshed from a user level Portal Cache entry, without having to contact the provider if the Portal Cache entry is still valid. The only drawback of combining the two types of caching is that the portlet developer must implement the PDK interfaces for both.
Documents (including images) that are stored in the portal are cached in the Portal Cache using validation-based caching.
All images on a page are cached in Web Cache unless the image is for an item whose item type is based on either the Image or Imagemap item type.
Portal also makes extensive use of images in the /images directory on the middle-tier file system. When Portal is installed, a Web Cache directive is created that sets the cache lifetime of these images to 2,592,000 seconds (30 days). This directive overrides Web Cache's default "cache forever" rule for images.
Portlets can define events, and those events (such as a button being clicked or a data value selected) can be mapped to page parameters to enable inter-portlet and inter-page communication.
Event metadata (the data that describes the behavior of an event) is cached in both Web Cache and the Portal Cache. The caching behavior for events is the same as for page definitions--a combination of invalidation-based and validation-based caching. Event definition cache entries will be invalidated when they are modified.
Providers can be passed login metadata that describes the current session so that they can track state for a Portal user. This session data is cached in Web Cache and passed to providers along with requests for portlet content.
If a page or portlet exists in multiple languages, a separate cache entry is maintained for each of the languages.
For more information about Oracle9iAS Web Cache, refer to the Web Cache documentation on Oracle Technology Network.
Changing how a page is cached
Clearing the cache
Setting the expiry time for invalidation-based caching