The scenario that we'll run in this example is described in the documentation for JBossCache. It consists of 2 separate nodes that replicate their contents between each other. In addition, they both point to the same datastore. The configuration is in file jboss-cache/output/etc/META-INF/replAsyncSharedCacheLoader-service.xml :

<!-- Whether or not to fetch state on joining a cluster -->
            <attribute name="FetchStateOnStartup">false</attribute>
            <attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute>
            <attribute name="CacheLoaderConfig">
            location=c:\\tmp
            </attribute>
            <attribute name="CacheLoaderShared">true</attribute>
            <attribute name="CacheLoaderPreload">/</attribute>
            <attribute name="CacheLoaderFetchTransientState">false</attribute>
            <attribute name="CacheLoaderFetchPersistentState">true</attribute>

The FetchStateOnStartup attribute set to false means that a newly started cache will not attempt to fetch the state (neither transient nor persistent). Therefore, attributes CacheLoaderFetchTransientState and CacheLoaderFetchPersistentState will be ignored. CacheLoaderShared set to true means that both nodes will share the same datastore, which resides in c:\tmp in the example (this assumes that both nodes have access to the same file system). Please make sure that c:\tmp exists, or point the config string to a different existing directory.

This configuration would essentially provide for two cold nodes, in the sense that all contents of a new cache is in the datastore, and is lazy-loaded via the CacheLoader when accessed. However, this is not true, as CacheLoaderPreload points to "/", which is the root of the entire tree. Therefore, all of the contents of the cache are recursively pre-loaded. This is probably a bad configuration when you have a lot of data in the cache, because all of your data will be loaded into the cache.

Note that with a shared datastore, the node that makes a modification is the one who writes it to the store using the CacheLoader. This prevents both nodes from writing the same data twice.

We can now start 2 instances by opening two shells and executing the following ANT target:

bela@laptop /cygdrive/c/jboss-cache
            $ ./build.sh run.demo.async.shared.cacheloader
            Buildfile: build.xml

            init:

            compile:

            run.demo.async.shared.cacheloader:
            [java] ** node loaded: /a
            [java] ** node loaded: /a/b
            [java] ** node loaded: /a/b/c
            [java] ** node loaded: /uno
            [java] ** node loaded: /uno/due

            [java] -------------------------------------------------------
            [java] GMS: address is 192.168.1.184:1357
            [java] -------------------------------------------------------
            [java] interceptor chain is:
            [java] class org.jboss.cache.interceptors.CallInterceptor
            [java] class org.jboss.cache.interceptors.ReplicationInterceptor
            [java] class org.jboss.cache.interceptors.CacheLoaderInterceptor
            [java] class org.jboss.cache.interceptors.TransactionInterceptor
            [java] ** view change: [192.168.1.184:1355|1] [192.168.1.184:1355,
	    192.168.1.184:1357]
            [java] ** node modified: /
         

2 GUI instances will appear, showing the tree structure of the cache graphically. Nodes can be added, modified or removed by right-clicking or using the menu. Any modification is replicated between the two nodes. If both nodes are killed, and subsequently one or both nodes are restarted, the state is the same as before shutdown as it was persisted to the shared store via the CacheLoader.

Note that the example above shows the 2 nodes running on the same machine (192.168.1.184) on ports 1355 and 1357.