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

Tue Aug 29 16:00:34 EDT 2006

  User: gzamarreno
  Date: 06/08/29 16:00:34

  Modified:    docs/TreeCache/en  Tag:
                        Branch_JBossCache_1_2_4_SP2_JBCACHE-753 master.xml
  Log:
  [JBCACHE-753] Port the fix for JBCACHE-650 to 1.2.4SP2
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.12.2.4.10.2.6.1 +36 -0     JBossCache/docs/TreeCache/en/master.xml
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: master.xml
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/docs/TreeCache/en/master.xml,v
  retrieving revision 1.12.2.4.10.2
  retrieving revision 1.12.2.4.10.2.6.1
  diff -u -b -r1.12.2.4.10.2 -r1.12.2.4.10.2.6.1
  --- master.xml	21 Feb 2006 19:34:53 -0000	1.12.2.4.10.2
  +++ master.xml	29 Aug 2006 20:00:34 -0000	1.12.2.4.10.2.6.1
  @@ -1053,6 +1053,8 @@
          &lt;attribute name="CacheLoaderFetchTransientState"&gt;false&lt;/attribute&gt;
          &lt;attribute name="CacheLoaderFetchPersistentState"&gt;true&lt;/attribute&gt;
          &lt;attribute name="CacheLoaderAsynchronous"&gt;true&lt;/attribute&gt;
  +       &lt;attribute name="CacheLoaderSingleton"&gt;false&lt;/attribute&gt;
  +       &lt;attribute name="CacheLoaderPushWhenCoordinator"&gt;false&lt;/attribute&gt;
       &lt;/mbean&gt;
   </programlisting></para>
   
  @@ -1178,6 +1180,40 @@
         asynchronously, and it is thus impossible to guarantee when (and even
         if) a write succeeds. This needs to be kept in mind when setting the
         <literal>CacheLoaderAsynchronous</literal> property to true.</para>
  +      
  +      <para><literal>CacheLoaderSingleton</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>CacheLoaderConfig</literal>. Default value is false.
  +      </para>
  +
  +      <para><literal>CacheLoaderPushWhenCoordinator</literal> is only relevant
  +      if <literal>CacheLoaderSingleton</literal> has been set to true. When
  +      there's a change in the cluster topology which leads to the election of
  +      a new coordinator, setting this to true allows the new coordinator to
  +      persist the entire in-memory state to underlying cache loader as soon it
  +      acquires this role. 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
  +      <literal>CacheLoaderSingleton</literal> and <literal>
  +      CacheLoaderPushWhenCoordinator</literal> properties:</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>
   
       <section>