cziegeler 01/06/22 02:13:23
Modified: xdocs caching.xml
Log:
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>
<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.
-</p>
-<p>
-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 interface.
-This interface has two method:
-- generateKey() to generate a unique key within the space of the component ,e.g for
the FileGenerator
-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.
-</p>
</s1>
<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 cached
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 checks
+ 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> it
+ 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 the
+ file generator stores the last modification date of the xml
document parsed
+ in the validity object.</p>
+ <p>When a response is cached all validity objects are stored
together with
+ 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
caching
+ algorithm also collects all uptodate cache validity objects.
So if the
+ 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 into
+ the pipeline. If they are not valid any more the cached
response is removed
+ from the cache, the new response is generated and then stored
together with
+ the new validity objects in the cache.</p>
+ <s3 title="Examples">
<p>Guess what! Yes, forthcoming.</p>
</s3>
</s2>
+ <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.
+</p>
+ </s2>
</s1>
<s1 title="Caching of stream pipelines">
<p>Forthcoming.</p>
@@ -91,7 +86,21 @@
<p>Description of the interfaces is forthcoming</p>
</s1>
<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 some
+ methods for the <link
href="http://www.serve.net/buz/hash.adt/java.000.html";>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>
</s1>
</body>
</document>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
