cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vgritse...@apache.org
Subject cvs commit: xml-cocoon2/xdocs mrustore.xml
Date Sun, 22 Jul 2001 20:09:34 GMT
vgritsenko    01/07/22 13:09:34

  Modified:    xdocs    Tag: cocoon_20_branch mrustore.xml
  Log:
  Doc update from Gerhard Froehlich [g-froehlich@gmx.de]
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.1.2.2   +30 -26    xml-cocoon2/xdocs/mrustore.xml
  
  Index: mrustore.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon2/xdocs/mrustore.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- mrustore.xml	2001/07/20 10:29:34	1.1.2.1
  +++ mrustore.xml	2001/07/22 20:09:33	1.1.2.2
  @@ -2,21 +2,20 @@
   <!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
   <document>
     <header>
  -	 <title>MRUMemoryStore</title>
  -	 <subtitle>in Cocoon 2</subtitle>
  -	 <version></version>
  -	 <type>Technical document</type>
  -	 <authors><person name="Gerhard Froehlich" email="g-froehlich@gmx.de"/>
  -	 </authors>
  -	 <abstract>This document explains how the MRUMemoryStore under Cocoon 2 executes.</abstract>
  +    <title>MRUMemoryStore in @doctitle@</title>
  +    <version></version>
  +    <type>Technical document</type>
  +    <authors><person name="Gerhard Froehlich" email="g-froehlich@gmx.de"/>
  +    </authors>
  +    <abstract>This document explains how the MRUMemoryStore under @docname@ executes.</abstract>
     </header>
     <body>
     <s1 title="Goal">
  -		<p>This document explains how the MRUMemoryStore under Cocoon 2 executes.</p>
  -	</s1>
  -	<s1 title="Overview">
  -		<p>The MRUMemoryStore was developed to provide a standard algorithm to
  -       store data in Memory. For web-based applications the MRU (Most Recently Used) algorithm
  +    <p>This document explains how the MRUMemoryStore under @docname@ executes.</p>
  +  </s1>
  +  <s1 title="Overview">
  +    <p>The MRUMemoryStore was developed to provide a standard algorithm to
  +       store data in memory. For web-based applications the MRU (Most Recently Used) algorithm
          is very suitable, because the most accessed object is always on "top".
       </p>
       <p> If configured the objects are also swaped to the filesystem, to hold them
  @@ -35,9 +34,9 @@
       If the list is already full, the <code>free()</code> method is called and
the oldest,
       the last one in the LinkedList, data entry is also removed from the HashMap and the
       LinkedList.
  -    If an entry was already in the list, it is removed with a call to the <code>free()</code>

  -    method and inserted at the front of the list with a call to the <code>store()</code>
method. 
  -
  +    When calling the <code>get()</code> method, the store returns the object
by key
  +    and inserts the requested key on the top of the LinkedList.
  +       
       This implementation keeps only the most recent objects in the cache and provides the
best
       use of the machines memory.
       </p>
  @@ -47,15 +46,20 @@
       Caching in Memory is fast, but when the JVM restarts your processed Objects are gone
and
       must be processed again, although they didn't have changed. What a waste of CPU time.
       </p>
  +    <p>
  +    If configured, the MRUMemoryStore will keep your objects not only in memory, rather
also on
  +    the filesystem. When calling the <code>store()</code> method, objects are
pushed on a stack,
  +    which is processed by a "writerthread" in the background. This thread pops the object
from the
  +    stack and serialize it to the fs. So the objects are asynchron written to the filesystem,

  +    to keep the performance fast. The thread sleeps and awakes only, when one or more objects
  +    are pushed on the stack. But only CacheStreamObject's and CacheEventObject's in the
moment
  +    are stored on the filesystem.
  +    </p>
       <p>
  -    If configured, the MRUMemoryStore will keep your objects not only in Memory, rather
also on
  -    the filesystem. When calling the <code>store()</code> method, objects are
pushed on a stack
  -    which is processed by a "writerthread" in the backgroud. So the object are asynchron
written
  -    to the filesystem, to keep the performance fast. But only CacheStreamObject's and CacheEventObject's
  -    are stored on the filesystem. Because they are serializable. If you restart the JVW
the memory
  -    is clean and the <code>get()</code> method looks on the filesystem, if
the requested object
  -    is there, deserialize it and give it back to the caller. After all, the <code>store()</code>
  -    method is called and the deserialized object is stored in memory for further usage.
  +    If you restart your application memory is clean. When you request an object with the
<code>get()</code> 
  +    method the filesystem is checked if the requested object is available, deserialize
it and give 
  +    it back to the caller. After all the <code>store()</code> method is called
and the 
  +    deserialized object is stored in memory for further usage.
       </p>
       </s2>
       <s2 title="Background threads">
  @@ -64,8 +68,8 @@
       It will try to keep overall memory usage below the requested levels.
       </p>
       <p>
  -    The Writer Thread is notfied when a object is pushed on the stack to be written on
the filesystem.
  -    Then Writer Thread kicks in and serialize the object on the filesystem.
  +    The Writer Thread is notified when an object is pushed on the stack to be written on
the filesystem.
  +    Then Writer Thread kicks in and serialize the objects on the filesystem.
       </p>
       </s2>
     </s1>
  @@ -85,7 +89,7 @@
     </source> 
     <p>If you want to use the MRUMemoryStore as your EventCache:</p>
     <ol> 
  -      <li><code>&lt;event-cache class="org.apache.cocoon.components.store.MRUMemoryStore"&gt;</code>
  +      <li><code>&lt;event-cache class="org.apache.cocoon.components.store.MRUMemoryStore"&gt;</code>:
         Assigns the MRUMemoryStore as the actual EventCache.</li>
   			<li><code>&lt;parameter name="freememory" value="1000000"/&gt;</code>:

         Indicates how much memory should be left free in the JVM for normal operation..</li>
  
  
  

----------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org


Mime
View raw message