[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