Defining the Oracle Web Cache Invalidation Port If you are using an Oracle

7-68 Oracle Fusion Middleware Developers Guide for Oracle Portal when you click OK or Apply in Edit mode, thus causing new markup to be generated based on the personalized settings. The maximum time for holding the page in the cache is the minimum of the following: ■ Maximum expiry time from Oracle Portal defined in the Cache tab of the Global Settings page. ■ Web Provider default 24 hours if no maximum expiry time is specified by Oracle Portal. ■ The time in minutes of the pageExpires tag, if present. The following excerpt from provider.xml specifies that this portlet shall be cached for up to 5 minutes and shall be automatically invalidated upon personalization: renderer class=oracle.portal.provider.v2.render.RenderManager contentTypetexthtmlcontentType renderContainertruerenderContainer autoRedirecttrueautoRedirect autoInvalidatetrueautoInvalidate showPage class=oracle.portal.provider.v2.render.http.ResourceRenderer resourcePathhtdocsinvalidationinvalidation1.jspresourcePath useInvalidationCachingtrueuseInvalidationCaching pageExpires5pageExpires showPage editPage class=oracle.portal.sample.v2.devguide.invalidation. InvalidationEditRenderer renderer For more information on the syntax of provider.xml, refer to the provider Javadoc on OTN: http:www.oracle.comtechnologyproductsiasportalhtmljavadocxml_ tag_reference_v2.html

7.2.9.4.4 Manually Invalidating the Cache You may want the cached version of the portlet

invalidated when a request is processed or information somewhere has been updated. In these cases, you may want to manually invalidate the cache. The invalidation-based caching portlet sample included with PDK-Java contains a single portlet that displays the time the content was cached and a link to trigger an invalidation request. The first time a page request is made to the Web provider through the cache, the response is cached. Subsequent requests for the portlet content are fulfilled by returning content from Oracle Web Cache. When you click the link at the bottom of the portlet an invalidation request is generated by the provider that removes the portlet from the cache. The next request for the portlet is forwarded to the provider and the provider generates a new portlet with the current time. To perform invalidation calls to Oracle Web Cache, first you need to have a handle to a ServletInvalidationContext object. You can get this handle by calling the static getServletInvalidationContext method of the ServletInvalidationContextFactory class. Note: The pageExpires tag is also used for normal expiry based caching. These two forms of caching are mutually exclusive. Invalidation-based caching takes place in an Oracle Web Cache instance located in the same place as the Web provider. Pages stored using expiry based caching are cached in the middle tier of Oracle Portal. Enhancing Java Portlets 7-69 Once you have the handle, you need to specify the cache key. In the cache key, you need to specify whether you want to invalidate a particular portlet instance, all the instances of a portlet, or all the portlets managed by a provider. To perform this task, you use the methods of the ServletInvalidationContext class or the methods of its super class, InvalidationContext. This is where you can specify whether the portlet should be cached for this particular user USER level. If there is no user specified in the cache key, then the cached content is returned to all users, which means you are using SYSTEM level caching. The following example invalidates a portlet instance and calls the setFullProviderPath and setPortletReference methods. When the caching key is set, you call the invalidate method on the InvalidationContext object that sends the invalidation message to Oracle Web Cache. ServletInvalidationContext inv = ServletInvalidationContextFactory.getServletInvalidationContext; inv.setFullProviderPath ServletPortletRenderRequestpReq; inv.setPortletReference pReq.getPortletReference; int num = inv.invalidate; Review the Web cache sample provider for more information.

7.2.9.5 Adding Validation-Based Caching

Adding validation-based caching requires slightly more effort, but gives you explicit control over exactly which requests to your provider are cache hits. As an example, you may want to update the cache only when data within the portlet has changed. To implement this algorithm, you need to override the prepareResponse method. The signature of the BaseManagedRenderer.prepareResponse method is: public boolean prepareResponsePortletRenderRequest pr throws PortletException, PortletNotFoundException In your version of prepareResponse, you need to do the following: ■ Retrieve the cached version identifier set by the PPE in the render request by calling the HttpPortletRendererUtil.getCachedVersion method: public static java.lang.String getCachedVersion PortletRenderRequest request ■ If the portlet finds the previously cached version valid, the appropriate header has to be set by calling the HttpPortletRendererUtil.useCachedVersion method. It also instructs the RenderManager that it wont be necessary to call renderBody to render the portlet body. public static void useCachedVersionPortletRenderRequest request Otherwise, use HttpPortletRendererUtil.setCachedVersion to generate a new version of the portlet, which will be cached. It also indicates to the PPE that the renderBody method has to be called to regenerate the portlet content. public static void setCachedVersionPortletRenderRequest request, java.lang.String version, int level throws java.lang.IllegalArgumentException