[jbosscache-commits] JBoss Cache SVN: r4442 - core/trunk/src/main/docbook/userguide/en/modules.

[jbosscache-commits at lists.jboss.org]

Author: bstansberry at jboss.com
Date: 2007-08-27 13:11:11 -0400 (Mon, 27 Aug 2007)
New Revision: 4442

Modified:
   core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml
Log:
Add more passivation docs

Modified: core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml
===================================================================
--- core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml	2007-08-26 03:18:52 UTC (rev 4441)
+++ core/trunk/src/main/docbook/userguide/en/modules/cache_loaders.xml	2007-08-27 17:11:11 UTC (rev 4442)
@@ -1,4 +1,7 @@
-<chapter id="cache_loaders">
+
+
+         <orderedlist>
+            <listitem><chapter id="cache_loaders">
    <title>Cache Loaders</title>
    <para>JBoss Cache can use a
       <literal>CacheLoader</literal>
@@ -1064,6 +1067,64 @@
          When passivation is used, only the first cache loader configured is
          used and all others are ignored.
       </para>
+      
+      <section>
+      	<title>Cache Loader Behavior with Passivation Disabled vs. Enabled</title>
+      	
+      	<para>
+      	When passivation is disabled, whenever an element is modified, added or 
+      	removed, then that modification is persisted in the backend store via 
+      	the cache loader. There is no direct relationship between eviction and 
+      	cache loading. If you don't use eviction, what's in the persistent store 
+      	is basically a copy of what's in memory. If you do use eviction, what's 
+      	in the persistent store is basically a superset of what's in memory 
+      	(i.e. it includes nodes that have been evicted from memory). 
+      	</para>
+      	
+      	<para>
+      	When passivation is enabled, there is a direct relationship between 
+      	eviction and the cache loader. Writes to the persistent store via the 
+      	cache loader only occur as part of the eviction process. Data is deleted
+      	from the persistent store when the application reads it back into
+      	memory. In this case, what's in memory and what's in the persistent 
+      	store are two subsets of the total information set, with no intersection between the subsets.
+      	</para>
+      	
+      	<para>
+      	Following is a simple example, showing what state is in RAM and in the 
+      	persistent store after each step of a 6 step process:
+      	</para>
+      	
+         <orderedlist>
+            <listitem>Insert /A</listitem>
+			   <listitem>Insert /B</listitem>
+			   <listitem>Eviction thread runs, evicts /A</listitem>
+			   <listitem>Read /A</listitem>
+			   <listitem>Eviction thread runs, evicts /B</listitem>
+			   <listitem>Remove /B</listitem>
+			</orderedlist>
+			
+			<para> When passivation is disabled:</para>
+			<programlisting>
+1) RAM: /A     Disk: /A
+2) RAM: /A, /B Disk: /A, /B
+3) RAM: /B     Disk: /A, /B
+4) RAM: /A, /B Disk: /A, /B
+5) RAM: /A     Disk: /A, /B
+6) RAM: /A     Disk: /A
+			</programlisting>
+			
+			<para>When passivation is enabled:</para>		
+			<programlisting>
+1) RAM: /A      Disk:
+2) RAM: /A, /B  Disk:
+3) RAM: /B      Disk: /A
+4) RAM: /A, /B  Disk:
+5) RAM: /A      Disk: /B
+6) RAM: /A      Disk:
+      	</programlisting>      	
+      </section>
+      
    </section>
 
    <section>