cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From da...@cocoon.zones.apache.org
Subject [DAISY] Created: Cocoon Source Resolving - Stores
Date Tue, 20 Sep 2005 14:54:43 GMT
A new document has been created.

http://cocoon.zones.apache.org/daisy/legacydocs/708.html

Document ID: 708
Branch: main
Language: default
Name: Cocoon Source Resolving - Stores
Document Type: Document
Created: 9/20/05 2:54:26 PM
Creator (owner): Helma van der Linden
State: publish

Parts
=====

Content
-------
Mime type: text/xml
Size: 2472 bytes
Content:
<html>
<body>

<h1>The Store Components in Cocoon</h1>

<p>To keep cached data, Cocoon uses components implementing the
<em>org.apache.excalibur.Store</em> interface. Cocoon uses two implementations
of this interface, the "transient store" and the "store", and optionally a third
one, the "persistent store".</p>

<h1>The Transient store</h1>

<p>The transient store (role <em>Store.TRANSIENT_STORE</em> is used for
objects
that are not serializable, or whose storage doesn't make sense across server
restart. The transient store lives on its own and has no relation with other
stores. This is a mandatory component within Cocoon (i.e. used by Cocoon's
code). Transient store can drop stored components if system is running low on
memory.</p>

<p>Cocoon uses the transient store to cache XSLT style sheets, XSP logicsheets,
etc.</p>

<h1>The Store (aka "main Store")</h1>

<p>The store (role <em>Store.ROLE</em>) can hold not serializable objects
also.
It is a mandatory component, as the transient store. If memory is scarce, the
store can drop non serializable objects, and swaps serializable objects to disk.
For efficiency reasons, implementations of the store should swap out (or drop)
least often used objects. On shutdown, store can write out all objects residing
in memory to the disk.</p>

<p>Cocoon uses the main store to cache pipeline output.</p>

<h1>Persistent store (optional)</h1>

<p>Some store (<em>Store.ROLE</em>) implementations (but not all) may actually
be just an in-memory cache that swap objects by calling the persistent store
(<em>Store.PERSISTENT_STORE</em>) when needed. So the persistent store is an
<em>optional</em> component which is used only by MRUMemoryStore, and nowhere
else in the code.</p>

<p>Two examples to illustrate this:</p>

<ul>
<li>when using JISP, we had this mechanism : the store was a MRUMemoryStore
swapping to the persistent store which was a JISPStore.</li>
<li>JCS has its own in-memory front end to its own persistent storage. In this
configuration Store.ROLE will be a JCSStore and Store.PERSISTENT_STORE will have
no implementation, because we don't need it.</li>
</ul>

<h1>Summary</h1>

<ul>
<li>Store.TRANSIENT_STORE : used by Cocoon to store non-serializable objects
</li>
<li>Store.ROLE : used by Cocoon to store serializable objects</li>
<li>Store.PERSISTENT_STORE : optional component that may be used by in-memory
implementations of Store.ROLE to delegate persistent storage.</li>
</ul>

</body>
</html>

Collections
===========
The document belongs to the following collections: legacydocs

Mime
View raw message