Oracle Application Server 10g administration handbook: Cache invalidation

This is the fouth part of the six-part series on Oracle Application Server 10g administration.

The following is the fourth part of a six-part series on Oracle Application Server 10g administration. Each tip is excerpted from the Osborne Oracle Press book, "Oracle Application Server 10g administration handbook," by John Garmany and Don Burleson. Check back frequently for the next installment, or go to the main series page for all installments.

John Garmany and Don Burleson

John Garmany is the SearchOracle.com Oracle Application Server expert. John is senior Oracle trainer with Burleson Consulting, and a respected Oracle expert and author, chosen by Oracle Press to write the "officially authorized edition" of the "Oracle Application Server 10g administration handbook."

To view John's expert responses or to ask him a question, click here.

Don Burleson is a SearchOracle.com Oracle Internals experts. Don is founder of Burleson Consulting, and he is one of the world's top Oracle database experts with more than 20 years of full-time DBA experience.

To view Don's expert responses or to ask him a question, click here.


Cache invalidation

With the Internet containing helpful caches throughout its infrastructure, from the browser to the Web site, there must be a way to ensure that caches are not serving old content. Basic caching information is actually sent with the document when it is served.

Are static pages really static?

When you request a Web page, your browser will first look for that page in its own cache. If it finds it in the cache, it will include the Last-Modified time stamp in the HTTP 1.1 Request Header If-Modified-Since. If the page has not been modified, the server will return a 304 code (Not Modified), and the browser can serve the page from the cache.

Oracle's Web Cache will check the Last-Modified timestamp on the page in the cache and either send the fresh page or reply with the Not-Modified code. So how does Oracle's Web Cache know if the page in its cache is fresh? It uses a number of different methods, from monitoring headers like all caches, to being told by the application or database that content has changed. There are a number of HTTP headers in HTTP 1.1 to control caching of Web pages. The two main headers are the Expires and Cache-control.

  • Expires
    The Expires header contains a timestamp for when the page is no longer valid. For example, a Web page that displays sports scores may be updated every 30 minutes. As each page is served, the Expires header will contain the timestamp for the next update. If a cache services a request, it will know if the page contained in the cache is valid or if it should retrieve an updated version by the information in the Expires timestamp.
  • Cache-Control
    The Cache-control header defines in more detail which caches can cache the page. If the Cache-control is set to "public," any cache can cache the page. If Cache-control is set to "private," only the local cache should cache the page. A setting of "no-cache" means that the server must verify that the page is current before the browser can display it. A setting of "no-store" tells all caches not to cache the page. This would be used for a page that contains sensitive information that you don't want sitting around in caches. Other Cache-control parameters determine how long a page is fresh, such as "max-age" in seconds.
HTTP header information is necessary to define how caches maintain and serve you Web pages, but they are not capable of supporting dynamically generated Web pages.

Caching dynamic content

The Oracle Application Server 10g Web Cache is designed to cache dynamically generated content. When the Oracle HTTP Server (OHS) receives a request for nonstatic data, it passes that request to an application to create and serve the content. This may be a Java servlet that queries a database and formats the results, or a J2EE application.

Once the result is formatted, it is sent back to the requester. The results are cached in the Web Cache. The browser does not know that the page was created on the fly. The Web Cache, however, must have a mechanism to ensure that the page is still valid before re-serving the page to another request. The Web Cache must also ensure that the page is only served to the correct requester. If a brokerage firm has a Web site that displays your current holdings, the site must ensure that it serves your page only to you and not the next requester, which may be your neighbor. The Web Cache has this same problem of what page to serve for which request.

Go to the main series page.


About the authors

A senior Oracle trainer with Burleson Consulting, John Garmany is also a respected Oracle expert and author and chosen by Oracle Press to write the "officially authorized edition" for the "Oracle Application Server 10g administration handbook." John also serves as a writer for DBAZine, "Oracle Internals" and has authored several popular Oracle books.

Don Burleson is one of the world's top Oracle database experts with more than 20 years of full-time DBA experience. He specializes in creating database architectures for very large online databases and he has worked with some of the world's most powerful and complex systems. Don's professional Web sites include www.dba-oracle.com and www.remote-dba.net.

This was first published in July 2004

Dig deeper on Oracle Application Server

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchDataManagement

SearchBusinessAnalytics

SearchSAP

SearchSQLServer

TheServerSide

SearchDataCenter

SearchContentManagement

SearchFinancialApplications

Close