vgritsenko 01/07/22 13:07:49
Modified: xdocs mrustore.xml
Log:
Doc update from Gerhard Froehlich [[EMAIL PROTECTED]]
Revision Changes Path
1.3 +30 -25 xml-cocoon2/xdocs/mrustore.xml
Index: mrustore.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/xdocs/mrustore.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mrustore.xml 2001/07/20 10:30:02 1.2
+++ mrustore.xml 2001/07/22 20:07:49 1.3
@@ -2,20 +2,20 @@
<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
<document>
<header>
- <title>MRUMemoryStore in @doctitle@</title>
- <version></version>
- <type>Technical document</type>
- <authors><person name="Gerhard Froehlich" email="[EMAIL PROTECTED]"/>
- </authors>
- <abstract>This document explains how the MRUMemoryStore under @docname@
executes.</abstract>
+ <title>MRUMemoryStore in @doctitle@</title>
+ <version></version>
+ <type>Technical document</type>
+ <authors><person name="Gerhard Froehlich" email="[EMAIL PROTECTED]"/>
+ </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 @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
+ <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
@@ -34,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>
@@ -46,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">
@@ -63,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>
@@ -84,7 +89,7 @@
</source>
<p>If you want to use the MRUMemoryStore as your EventCache:</p>
<ol>
- <li><code><event-cache
class="org.apache.cocoon.components.store.MRUMemoryStore"></code>
+ <li><code><event-cache
class="org.apache.cocoon.components.store.MRUMemoryStore"></code>:
Assigns the MRUMemoryStore as the actual EventCache.</li>
<li><code><parameter name="freememory"
value="1000000"/></code>:
Indicates how much memory should be left free in the JVM for normal
operation..</li>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
