Differences between revisions 2 and 3
Revision 2 as of 2003-01-30 10:40:43
Size: 6442
Editor: anonymous
Comment: missing edit-log entry for this revision
Revision 3 as of 2003-05-01 10:13:57
Size: 2432
Editor: BertrandDelacretaz
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
In 2.1 and above, page authors are no longer required to generate their own hash key as a long value, and !CacheValidity has been replaced with the !SourceValidity interface. The previous example would be written in version 2.1 and above as the following: In 2.1 and above, page authors are no longer required to generate their own hash key as a long value, and !CacheValidity has been replaced with the !SourceValidity interface.
Line 29: Line 29:
{{{ <xsp:structure> The previous example would be written as follows in version 2.1 and above:

{{{<xsp:structure>
Line 34: Line 36:
  </xsp:structure> </xsp:structure>
Line 36: Line 38:
  <xsp:logic>
    public Serializable generateKey()
<xsp:logic>
    final int VALIDITY_SECS = 15;
    final int DELAY_SECS = 2;

    public Serializable getKey()
Line 39: Line 44:
  return "" + request.getParameter("param");        return "" + request.getParameter("pageKey");
Line 42: Line 47:
    public SourceValidity generateValidity() {
        return CacheValidityToSourceValidity.createValidity(
  new DeltaTimeCacheValidity(0, 5));
    public SourceValidity getValidity() {
       // keep in cache for VALIDITY_SECS
      
return CacheValidityToSourceValidity.createValidity(
           new DeltaTimeCacheValidity(0, VALIDITY_SECS));
Line 46: Line 52:
  </xsp:logic>}}}  </xsp:logic>}}}
Line 48: Line 54:
As you can see, the references to org.apache.cocoon.caching.!CacheValidity and org.apache.cocoon.util.!HashUtil are no longer required. In addition, you must include org.apache.excalibur.source.!SourceValidity, org.apache.cocoon.caching.!CacheValidityToSourceValidity, and java.io.Serializable to your list of includes (Java import statements). As of 2002-01-18, users who want to use simple timeout-based cache expiration (as is used in the cacheable XSP example) must continue using org.apache.cocoon.caching.!DeltaTimeCacheValidity, an implementation of !CacheValidity, as there is no equivalent implementation of the !SourceValidity interface. For the time being, !CacheValidityToSourceValidity acts as a bridge between the two APIs, enabling the use of older 2.0.x-compatible caching implementations in the newer versions of Apache Cocoon. As you can see, this needs several new xsp:includes for the changed API.
Line 50: Line 56:
More sophisticated caching can be implemented using custom implementations of !SourceValidity.
Line 52: Line 59:

As it happens, the existing code has a "problem." For example on a 1GHz Athlon workstation, it's quite likely that, after the initial XSP compilation step, the user will not be able to clearly see a speed difference between an uncached version and a cached version. In an attempt to simulate complexity, a complete example is included with a simple Thread.sleep(long) call. It is identical to Carsten Zielgler's example except for the 2.1 updates and a two second delay. With the delay, it is much easier for the user to recognize when the system is using a cached copy and when it is not. Obviously, for production code, you would not want this artificial delay -- don't forget to remove it.

----

{{{ <?xml version="1.0" encoding="ISO-8859-1"?>
  <xsp:page language="java"
          xmlns:xsp="http://apache.org/xsp"
          xmlns:xsp-request="http://apache.org/xsp/request/2.0">

  <xsp:structure>
    <xsp:include>org.apache.excalibur.source.SourceValidity</xsp:include>
    <xsp:include>org.apache.cocoon.caching.CacheValidityToSourceValidity</xsp:include>
    <xsp:include>org.apache.cocoon.caching.DeltaTimeCacheValidity</xsp:include>
    <xsp:include>java.io.Serializable</xsp:include>
  </xsp:structure>

  <xsp:logic>
    /**
     * Generate the unique key.
     * This key must be unique inside the space of this XSP page.
     * This method will be invoked before the generateValidity() method.
     *
     * @return The generated key or null if the component
     * is currently not cacheable.
     */
    public Serializable generateKey()
    {
        // Generate unique key; add parameters' values here
        return "" + request.getParameter("param");
    }

    /**
     * Generate the validity object.
     * Before this method can be invoked the generateKey() method
     * will be invoked.
     *
     * @return The generated validity object or null if the
     * component is currently not cacheable.
     */
    public SourceValidity generateValidity() {
        // Check all dependencies here
        return CacheValidityToSourceValidity.createValidity(
            new DeltaTimeCacheValidity(0, 5));
    }
  </xsp:logic>

  <page>
    <title>A Cacheable XSP Page</title>
    <content>

      <!-- Two second wait -->
      <xsp:logic>
        try {
          Thread.sleep(2000);
        } catch (InterruptedException ie) {
          // Not much that can be done...
        }
      </xsp:logic>

      <para>Hi there! I'm a simple dynamic page generated by XSP
        (eXtensible Server Pages).</para>
      <para>I'm cached for every different value of request parameter
        'param'. Value is: <b>
        <xsp-request:get-parameter name="param"/>
          </b></para>
      <para>All other request parameters do not influence cache status, but
        my validity will expire after 5 sec (see source).
        Value of parameter 'other' is: <b>
          <xsp-request:get-parameter name="other"/></b>
            </para>
      <para>Links:
        <ul>
        <li><a href="cacheable?param=one">param=one</a></li>
        <li><a href="cacheable?param=two">param=two</a></li>
        <li><a href="cacheable?param=three&amp;other=abc">param=three, other=abc</a></li>
        <li><a href="cacheable?param=three&amp;other=xyz">param=three, other=xyz</a></li>
        </ul>
        Try two last links with delay 5 sec; and try without delay.
          </para>
    </content>
  </page>

  </xsp:page>}}}

----

This should be a drop-in replacement for the existing version of cacheable.xsp in your 2.1 webapp.
There was an example here which didn't work with 2.1 M2-dev. I have updated and tested the Cocoon CVS example (file webapp/samples/xsp/xsp/cacheable.xsp), please refer to it for detailed info. -- BertrandDelacretaz

Changes since version 2.0.x

In the 2.0.x version of Apache Cocoon, the user would include the following in their cacheable XSP file prior to the output page content (I have removed the comments from the original sample for brevity's sake):

{{{ <xsp:structure>

  • </xsp:structure>

    <xsp:logic>

    </xsp:logic>}}}

In version 2.0.x of Apache Cocoon, the samples demonstrate how to implement cacheable XSP files using a combination of HashUtil and the CacheValidity interface.

New caching API for use in XSP (as well as other components)

In 2.1 and above, page authors are no longer required to generate their own hash key as a long value, and CacheValidity has been replaced with the SourceValidity interface.

The previous example would be written as follows in version 2.1 and above:

{{{<xsp:structure>

</xsp:structure>

<xsp:logic>

  • </xsp:logic>}}}

As you can see, this needs several new xsp:includes for the changed API.

More sophisticated caching can be implemented using custom implementations of SourceValidity.

Complete Example

There was an example here which didn't work with 2.1 M2-dev. I have updated and tested the Cocoon CVS example (file webapp/samples/xsp/xsp/cacheable.xsp), please refer to it for detailed info. -- BertrandDelacretaz

XSPCachingWithCocoonHEAD (last edited 2009-09-20 23:41:25 by localhost)