Untitled Document
Oracle ADF Faces Cache Tag Library
An Oracle Technical Document
May 2005
Index
Introduction
The Oracle ADF Faces Cache tag library enables fragment caching inside a J2EE container, such as Oracle Container for Java (OC4J) or Tomcat. As a component of the Oracle ADF Faces, the Oracle ADF Faces Cache tag library works with any implementation of the JavaServer Faces JSF 1.1 specification (or later).
The Oracle ADF Faces Cache library enables in-memory caching of the presentation layer of any JSF based applications and thus avoids content regeneration by the J2EE container. The results are an increase in throughput and a reduction on the total response time, especially for responses that require formatting of results from database queries. Because the Oracle ADF Faces Cache operates within the J2EE container, pages that are generally not cacheable, such as those requiring authentication, in an external cache would become cacheable. This is particularly beneficial for financial applications, HR applications, or any business applications that have complex application logic.
To use the Oracle ADF Faces Cache tag library, add the library into your desired J2EE container. As you build your application, simply mark fragments with a beginning <afc:cache> and ending </afc:cache> tag.
How Caching Works
The execution of a page containing fragments is as follows:
1. The browser client requests a page containing fragments delineated with <afc:cache> tag. A page can contain one or more cacheable fragments.
2. The application server receives the request. In the J2EE container, the cache tag handler looks for the fragment in the cache. If the fragment is not present or invalid, the cache tag handler generates fragments responses and stores a copy of the responses in the cache.
3. The application server returns the responses from the cache tag handler to the browser client.
4. When another browser client requests for the same fragment next time, the cache tag handler retrieves the fragment from the memory and assembles the page with the cached fragment content.
<afc:cache> Tag
The <afc:cache> tag is for specifying the caching policy of page fragments. For maximum caching and thus optimized performance results, use the <afc:cache> tag for page fragments that can be reused multiple times. Content that changes frequently may still be suitable for caching if there are many requests for it.
The general syntax of <afc:cache> is as follows:
<afc:cache [duration="seconds"]
[varyBy="varyBy_param.varyBy_param_value [varyBy_param.varyBy_param_value...]"]
[searchKeys="searchKey [searchKey...]"]
[cacheMissOnRePost="true|false"]>
cacheable content
</afc:cache>
To set cache properties for an entire page fragment, make the <afc:cache> tag a direct child of the <f:view> tag, and enclose the page's content within it:
page.jsp
<f:view>
<afc:cache ...>
cacheable page content
</afc:cache>
</f:view>
To set cache properties for fragments contained within a main page, enclose each fragment within a beginning <afc:cache> tag and ending </afc:cache> tag:
page.jsp
<f:view>
...
<afc:cache ...>
cacheable fragment content
</afc:cache>
...
<afc:cache ...>
cacheable fragment content
</afc:cache>
...
</f:view>
To set cache properties for a fragment that exists in its own subpage and is included (<jsp:include>) from the main page, make the <afc:cache> tag a direct child of the <f:subview> tag, and enclose the fragment's content within it. In this manner, you can share a cacheable fragment among different pages.
page.jsp
<f:view>
...
<afc:cache ...>
cacheable fragment content
</afc:cache>
<jsp:include page="/fragment.jsp" />
<afc:cache ...>
cacheable fragment content
</afc:cache>
...
</f:view>
fragment.jsp
<f:subview>
<afc:cache ...>
cacheable fragment content
</afc:cache>
</f:subview>
The <afc:cache> tag contains four attributes.
-
duration - Specifies the time, in seconds, that the fragment is valid in the cache.
-
varyBy - Specifies the range of versions of the fragment to be cached. You express varyBy as a space-separated list of elements that the page or fragment output varies by. The elements can be HTTP request headers, cookies, embedded URL parameters, country locales, user sessions, or bean properties. Each EL-like element is expressed as varyBy_param.varyBy_param_value, which can be any combination of the following:
header.header_name
cookie.cookie_name
param.param_name
view.locale
request.session
beanclass.property_name
You must specify varyBy_param.varyBy_param_value
If this attribute is not present in the tag, it defaults to a NULL value, meaning that only one version of the page or fragment is ever cached.
-
searchKeys - Specifies a space separated list of search keys to be associated with the cached content for purposes of programmatic invalidation.
You use search keys to organize Web pages and fragments into different groups. You can assign all the pages in a particular group with the same search key. For example, you assign the search key business_news to all the pages that have something to do with business news. To invalidate a group of objects, you submit an invalidation request that specifies the search key associated with that particular group. For example, if the invalidation request specifies the search key business_news, all the pages assigned the business_news search key will be invalidated.
You can assign an object more than one search key. For example, you can assign a Web page that tells a story about a local sports team search keys local_news and sports_news.
-
CacheMissOnRePost - Sets a policy for how the <afc:cache> tag handles a re-POST, a request that is the result of a POST back from the same page, such as an application performing a refresh operation or JSF sending an invalidation error.
true instructs the <afc:cache> tag to never render content from the cache and instead perform JSF encoding if the current request is a re-POST. In order words, the request will be treated as a cache miss. This value is appropriate for a fragment containing, for example, a button that does some calculation, such as a refresh query.
false instructs the <afc:cache> tag to fetch the fragment from the cache, even if the request is a re-POST. This value would be appropriate, for example, with a simple choice menu.
When this attribute is not set, the <afc:cache> tag does not check whether or not the request is a re-POST. It simply caches the fragment honoring the other attributes. However, if the fragment contains an input field, the fragment will not be cached. Oracle ADF Faces Cache assumes input fields have validators or converters associated with them.
Invalidation
Content invalidation takes place as part of the application logic. Oracle ADF Faces Cache provides an API for invalidation that is based on the search keys of the objects. For details, view the Javadoc.
Download Developer Preview and Example
Sign up for Java Newsletter and download the developer preview to see the Oracle ADF Faces Cache tag library in action. This zip file also contains a sample application. JDeveloper 10g (10.1.3) provides a fully functional JSF environment and is the recommended IDE for this exercise.
Summary
The Oracle ADF Faces Cache tag library enables fragment caching of the JavaServer Faces pages within the J2EE container. By simply inserting the <afc:cache> tag inside the JSF view tag, application developers can optimize application performance by incorporating caching. A developer preview of the Oracle ADF Faces Cache tag library is available now.
| 
Bookmark
