[jboss-cvs] JBossCache/docs/TreeCache/en/modules ...

Galder Zamarreno galder.zamarreno at jboss.com
Fri Sep 29 14:27:21 EDT 2006


  User: gzamarreno
  Date: 06/09/29 14:27:21

  Modified:    docs/TreeCache/en/modules  cache_loaders.xml
  Log:
  [JBCACHE-650] - SharedStoreCacheLoader refactored to SingletonStoreCacheLoader 
  adding the ability to push the in-memory state to the underlying cache loader when 
  assuming the coordinator role. Created AbstractDelegatingCacheLoader class that 
  contains basic delegating functionality. SingletonStoreCacheLoader and 
  AsyncCacheLoader now extend this class. Necessary configuration options added 
  and documentation has been updated to include explanation. Two singleton cache 
  sample configurations added too.
  
  Revision  Changes    Path
  1.10      +37 -0     JBossCache/docs/TreeCache/en/modules/cache_loaders.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: cache_loaders.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/TreeCache/en/modules/cache_loaders.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -b -r1.9 -r1.10
  --- cache_loaders.xml	19 Jul 2006 08:29:17 -0000	1.9
  +++ cache_loaders.xml	29 Sep 2006 18:27:21 -0000	1.10
  @@ -371,6 +371,11 @@
                       <!-- if set to true, purges the contents of this cache loader when the cache starts up.
                       Defaults to false.  -->
                       <purgeOnStartup>false</purgeOnStartup>
  +                    <!-- defines the cache loader as a singleton store where only the coordinator of the
  +                    cluster will store modifications. Setting pushStateWhenCoordinator to true enables a
  +                    newly elected coordinator to push the in-memory state to the underlying cache store.
  +                    Both default to false. -->
  +                    <singletonStore pushStateWhenCoordinator="false">false</singletonStore>
                   </cacheloader>
   
               </config>
  @@ -547,6 +552,38 @@
         </para>
       </section>
   
  +      <para><literal>singletonStore</literal> enables modifications to
  +      be stored by only one node in the cluster, the coordinator. This property
  +      can be set to true in all nodes, but only the coordinator of the cluster
  +      will store the modifications in the underlying cache loader as specified
  +      in the <literal>class</literal> element inside <literal>cacheloader
  +      </literal> element . You cannot define a cache loader as <literal>shared
  +      </literal> and <literal>singletonStore</literal> at the same time.
  +      Default value is false.</para>
  +
  +      <para><literal>pushStateWhenCoordinator</literal> allows the in-memory
  +      state to be pushed to the cache store when a node becomes the
  +      coordinator, as a result of the new election of coordinator due to a
  +      cluster topology change. This can be very useful in situations where the
  +      coordinator crashes and there's a gap in time until the new coordinator
  +      is elected. During this time, if this property was set to false and the
  +      cache was updated, these changes would never be persisted. Setting this
  +      property to true would ensure that any changes during this process also
  +      get stored in the cache loader. You would also want to set this property
  +      to true if each node's cache loader is configured with a different
  +      location. Default value is false.</para>
  +
  +      <para><emphasis role="bold">Note on using the
  +      <literal>singletonStore</literal> element:</emphasis> setting
  +      up a cache loader as a singleton and using cache passivation (via
  +      evictions) can lead to undesired effects. If a node is to be passivated
  +      as a result of an eviction, while the cluster is in the process of
  +      electing a new coordinator, the data will be lost. This is because no
  +      coordinator is active at that time and therefore, none of the nodes in
  +      the cluster will store the passivated node. A new coordinator is elected
  +      in the cluster when either, the coordinator leaves the cluster, the
  +      coordinator crashes or stops responding.</para>
  +
       <section>
         <title>Cache passivation</title>
   
  
  
  



More information about the jboss-cvs-commits mailing list