Exporting by Reference Example To export by reference rather than exporting

Enhancing Java Portlets 7-63

7.2.9 Enhancing Portlet Performance with Caching

In the previous sections of this chapter, you learned how to write fully-functional Java portlets using the PDK Framework. Once you complete the basic functionality of your portlet, you may want to turn your attention to portlet performance. Caching is a common technique for enhancing the performance of Web sites that include a great deal of dynamic content. The overhead involved in retrieving data and generating the output for dynamic content can be significantly reduced by proxying requests through a local agent backed by a large, low-latency data store known as a cache. The cache agent responds to a request in one of two ways, as follows: ■ If a valid version of the requested content exists in the cache, the agent simply returns the existing cached copy, thus skipping the costly process of content retrieval and generation. This condition is called a cache hit. ■ If a valid version of the requested content does not exist in the cache, the agent forwards the request to its destination and awaits the return of the content. The agent returns the content to the requestor and stores a local copy in its cache for reuse if a subsequent request for the same content arises. This condition is called a cache miss. Web providers generate dynamic content that is, portlets and they often reside remotely from the Oracle Portal instance on which they are deployed. As such, caching might improve their performance. The architecture of Oracle Portal lends itself well to caching, since all rendering requests originate from a single page assembling agent, known as the Parallel Page Engine PPE, which resides on the middle tier. You can make the PPE cache the portlets rendered by your Web provider and reuse the cached copies to handle subsequent requests, minimizing the overhead your Web provider imposes on page assembly. The Web provider can use any one of three different caching methods, depending upon which one is best suited to the application. The methods differ chiefly in how they determine whether content is still valid. Following are the three caching methods:

1. Expiry-based Caching

: When a provider receives a render request, it stamps its response with an expiry time. The rendered response remains in the cache and fills all subsequent requests for the same content until its expiry time passes. This caching scheme is perhaps the simplest and most performant because the test for cache validity requires very little overhead and does not involve any network round trips. Expiry-based caching suits applications where the content has a well-defined life span. For content with a less certain life span, however, expiry-based caching is less effective. Refer to Section 7.2.9.2, Activating Caching and Section 7.2.9.3, Adding Expiry-Based Caching for more information.

2. Invalidation-based Caching:

Invalidation-based caching works essentially the same way as expiry-based caching, except that the contents of the cache can expire or become invalid at any time. Invalidation of cache content is usually triggered by an event. For example, if you have a calendar portlet that shows your appointments for the day, the content for the portlet could be generated once, the first time you show the calendar for that day. The content remains cached until something happens to change your schedule for that day, such as the addition of an appointment, the deletion of an existing appointment, or a change of time for an appointment. Each of these change events can trigger an action in the calendar application. When such an event takes place, your calendar application can generate an invalidation request for any cached portlet content affected by the change. The next time you view a page containing your calendar portlet, the cache will not contain an entry. 7-64 Oracle Fusion Middleware Developers Guide for Oracle Portal Your Web provider will be contacted to regenerate the new content with the modified schedule. This method is a very efficient way to cache content because the originator of the content, that is, your Web provider, is contacted only when new content needs to be generated, but you are not bound to a fixed regeneration schedule. Refer to Section 7.2.9.2, Activating Caching and Section 7.2.9.4, Adding Invalidation Based Caching for more information.

3. Validation-based Caching

: When a provider receives a render request, it stamps its response with a version identifier or E Tag. The response goes into the cache, but, before the PPE can reuse the cached response, it must determine whether the cached version is still valid. It sends the provider a render request that includes the version identifier of the cached content. The provider determines whether the version identifier remains valid. If the version identifier is still valid, the provider immediately sends a lightweight response to the PPE without any content, which indicates the cached version can be used. Otherwise, the provider generates new content with a new version identifier, which replaces the previously cached version. In this form of caching, the PPE must always confirm with the provider whether the content is up to date. The validity of the cached copy is determined by some logic in the provider. The advantage of this approach is that the provider controls the use of the cached content rather than relying on a fixed period of time. Refer to Section 7.2.9.2, Activating Caching and Section 7.2.9.5, Adding Validation-Based Caching for more information.

7.2.9.1 Assumptions

To perform the tasks in these sections, we are making the following assumptions:

1. You have followed through and understood

Section 6.5, Building Oracle PDK-Java Portlets with Oracle JDeveloper .

2. You built a portlet using the wizard and successfully added it to a page.

7.2.9.2 Activating Caching

To use the caching features of Oracle Portal in your Web providers, you must first activate the middle tier cache. This cache is known as the PLSQL Cache because it is the same cache used by mod_plsql, the Oracle HTTP Server plug-in that calls database procedures, and hence database providers, over HTTP. Usually, your OracleAS Portal administrator is responsible for the configuration details of caching. For invalidation-based caching, you need to configure Oracle Web Cache in front of the Web provider. Bear in mind that remote Web providers often do not have Oracle Web Cache installed. For more information about Oracle Web Cache, refer to the Oracle Fusion Middleware Administrators Guide for Oracle Web Cache. Once you have installed and configured Oracle Web Cache, ensure the following in the Oracle Web Cache Manager: ■ It points to the host name and port of the Web provider. ■ Caching rules do not cause the caching of provider content. Content should be cached according to the surrogate control headers generated by the provider in its response. Enhancing Java Portlets 7-65

7.2.9.3 Adding Expiry-Based Caching

Expiry-based caching is one of the simplest caching schemes to implement, and can be activated declaratively in your XML provider definition. You can set an expiry time for the output of any ManagedRenderer you utilize by setting its pageExpires property to the number of minutes you want the output to be cached for. For example, suppose you want portlet output to be cached for one minute. To add expiry-based caching, perform the following steps:

1. After you have used the Portlet Wizard to build a portlet as described in

Section 6.5, Building Oracle PDK-Java Portlets with Oracle JDeveloper , edit the provider.xml file and set the pageExpires property tag of showPage to 1. This will set an expires entry of 1 minute for the portlet. By default the wizard generates a standard and compressed tag for showPage. You need to expand the tag to include a subtag of pageExpires: showPage class=oracle.portal.provider.v2.render.http.ResourceRenderer resourcePathhtdocsmycacheportletMyCachePortletShowPage.jsp resourcePath pageExpires1pageExpires showPage For more information on the syntax of provider.xml, refer to the provider Javadoc on OTN: http:www.oracle.comtechnologyproductsiasportalhtmljavadocx ml_tag_reference_v2.html 2. Test that the portlet is cached for 1 minute by adding some JSP code to your show page. You can simply add the current time to your JSP. page contentType=texthtml; charset=windows-1252 import=oracle.portal.provider.v2.render.PortletRenderRequest import=oracle.portal.provider.v2.http.HttpCommonConstants import=java.util.Date import=java.text.DateFormat PortletRenderRequest pReq = PortletRenderRequest request.getAttributeHttpCommonConstants.PORTLET_RENDER_REQUEST; DateFormat df = DateFormat.getDateTimeInstanceDateFormat.LONG, DateFormat.LONG,pReq.getLocale; String time = df.formatnew Date; PHello =pReq.getUser.getName .P PThis is the biEditib render modeP PThis information is correct as of =time.P When viewing the portlet, you see that the time including seconds is constant for 1 minute. After the time has expired, the portlet displays the most current time and a new cache is set.

7.2.9.4 Adding Invalidation Based Caching

When using Oracle Web Cache, requests for content are sent using HTTP and content is either returned from the cache or the HTTP request is forwarded to the originator of the content. When content is returned to Oracle Web Cache, it is added to the cache before being returned to the requestor. Cache content is invalidated by sending