Hi Team, I wrote a xdoc for the MRUMemoryStore. Feel free to commit it. But the english grammer may be awfull (Germans and the english language :-) Cheers Gerhard -- Gerhard Fröhlich [EMAIL PROTECTED] "black holes are, when GOD is dividing by zero" GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net GMX Tipp: Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409aTitle: MRUMemoryStore
This document explains how the MRUMemoryStore under Cocoon 2 executes.
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".
If configured the objects are also swaped to the filesystem, to hold them in an persitent state over JVM restarts.
The heart of the MRUMemoryStore ist combination of a LinkedList and a HashMap:
The LinkedList provides the queue mechanism, and the entries in the LinkedList
contain the key to the data in the HashMap. When calling the store()
method a new entry to the front of the list is inserted.
If the list is already full, the free() 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 free()
method and inserted at the front of the list with a call to the store() method.
This implementation keeps only the most recent objects in the cache and provides the best
use of the machines memory.
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.
If configured, the MRUMemoryStore will keep your objects not only in Memory, rather also on
the filesystem. When calling the store() 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 get() method looks on the filesystem, if the requested object
is there, deserialize it and give it back to the caller. After all, the store()
method is called and the deserialized object is stored in memory for further usage.
The CleanUp Thread checks that memory is not running too low in the JVM because of the Store. It will try to keep overall memory usage below the requested levels.
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.
If you want to use the MRUMemoryStore as your EventCache:
Assigns the MRUMemoryStore as the actual EventCache.: Indicates how much memory should be left free in the JVM for normal operation..: Indicates how big the heap size can grow to before the cleanup thread kicks in.: Indicates the interval of the cleanup thread in seconds.: Indicates how many objects will be hold in the cache. When the number of maxobjects has been reached. The last object in the cache will be thrown out.: Indicates whether we use a cleanup thread or not.: Indicates the priority of the background threads. 1 is the lowest priority and 10 is the highest.: Turns the filesystem storage for objects on or off.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
