cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: xml-cocoon2/xdocs caching.xml
Date Fri, 22 Jun 2001 09:13:23 GMT
cziegeler    01/06/22 02:13:23

  Modified:    xdocs    caching.xml
  Small docs update
  Revision  Changes    Path
  1.5       +41 -32    xml-cocoon2/xdocs/caching.xml
  Index: caching.xml
  RCS file: /home/cvs/xml-cocoon2/xdocs/caching.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- caching.xml	2001/06/20 14:47:38	1.4
  +++ caching.xml	2001/06/22 09:13:23	1.5
  @@ -16,35 +16,6 @@
   	 <s1 title="Overview">
   		<p>Overview is forthcoming</p>
  -<p>     Responsible for the caching are the CachingPipelines.
  -     When a sitemap is processed, this classes asking every
  -     sitemap component (generator, transformer,serializer)
  -     if they are cachable. If the component is cachable, it
  -     has to provide one key and one ValidityObject.
  -     Now the CachingPipeline builds from this provided keys
  -     one unique key for the pipeline and memorizes every
  -     ValidityObjects. The cache (interface EventCache/StreamCache)
  -     only stores CachedEventObjects and CachedStreamObjects.
  -     The key for those object is calculated one from the
  -     CachingPipeline.
  -The concept of the caching is based on the various discussions and my own thoughts...So
here only a short overview:
  -The sitemap components (currently Generator and Transformer) can implement the Cacheable
  -This interface has two method: 
  -- generateKey() to generate a unique key within the space of the component ,e.g for the
  -this key is a hash of the source argument. (For this I added the HashUtil class which provides
the BuzHash algorithm). 
  -- generateValidity() the validity which checks if the cached content is still valid, e.g.
for the FileGenerator
  - this is the TimeStamp of the xml file. The Caching Algorithm now checks all pipeline components
for the
  - Cacheable interface and builds a unique key from these Components (starting from the generator
just to
  - the point before the first not Cacheable component). This key is used to get a CachedObject
from the 
  -EventCache (actually a Store). The CachedObject (if available) contains the cached content
and all validity 
  -objects when this was cached. The next stage compares the current validity objects with
the cached ones.
  - If they are all valid the cached response is used. If something failes during this algorithm,
a new response is
  - generated and this result is cached. </p> 
  -<p>The storing of the sax events is implemented by two more 
  -Avalon components the XMLSerializer and the XMLDeserializer. 
   	 <s1 title="Caching of event pipelines">
   		<p>The algorithm used for caching depends on the configured event pipeline. 
  @@ -75,11 +46,35 @@
   			<p>Now after the key is build for this particular request, it is looked up
                        in the cache if it exists. If not, the new request is generated and
                        for further requests.</p>
  -			<p>To be continued...</p>
  -			<s3 title="Example">
  +                  <p>If a cached response is found for the key, the caching algorithm
  +                     if this response is still valid. For this check each cacheable component
  +                     returns a validity object when the method <code>generateValidity</code>
  +                     is invoked. (If a cacheable component returns <code>null</code>
  +                     is temporarily not cacheable, like returning <code>0</code>
for the key.)</p>
  +                  <p>A <code>CacheValidity</code> object contains all
information the component
  +                     needs to verify if the cached content is still valid. For example
  +                     file generator stores the last modification date of the xml document
  +                     in the validity object.</p>
  +                  <p>When a response is cached all validity objects are stored together
  +                     the cached response in the cache. Actually the <code>CachedEventObject</code>
  +                     is stored which encapsulates all this information.</p>
  +                  <p>When a new response is generated and the key is generated, the
  +                     algorithm also collects all uptodate cache validity objects. So if
  +                     cached response is found in the cache these validity objects are compared.
  +                     If they are valid (or equal) the cached response is used and feed
  +                     the pipeline. If they are not valid any more the cached response is
  +                     from the cache, the new response is generated and then stored together
  +                     the new validity objects in the cache.</p>
  +			<s3 title="Examples">
   				<p>Guess what! Yes, forthcoming.</p>
  +		<s2 title="The XMLSerializer/XMLDeserializer">
  +			<p>Forthcoming. Believe me!</p>
  +<p>The storing of the sax events is implemented by two more 
  +Avalon components the XMLSerializer and the XMLDeserializer. 
  +		</s2>
   	 <s1 title="Caching of stream pipelines">
  @@ -91,7 +86,21 @@
   		<p>Description of the interfaces is forthcoming</p>
   	 <s1 title="Utility classes">
  -		<p>Description of HashUtil is forthcoming</p>
  +		<s2 title="Hash Util">
  +			<p>The <code>org.apache.cocoon.util.HashUtil</code> class provides
  +                     methods for the <link href="">BuzHash
algorithm by Robert Uzgalis</link>.</p>
  +    <source>
  +     <![CDATA[
  +       package org.apache.cocoon.util;
  +       public class HashUtil {
  +         public static long hash(String arg);
  +         public static long hash(StringBuffer arg);
  +       }
  +     ]]>
  +    </source>
  +		</s2>

In case of troubles, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message