JBoss.org Community Documentation
The state that is acquired and integrated can consist of two basic types:
"Transient" or "in-memory" state. This consists of the actual in-memory state of another cache instance - the contents of the various in-memory nodes in the cache that is providing state are serialized and transferred; the recipient deserializes the data, creates corresponding nodes in its own in-memory tree, and populates them with the transferred data.
"In-memory" state transfer is enabled by setting the cache's
FetchInMemoryState
configuration attribute to
true
.
"Persistent" state. Only applicable if a non-shared cache loader is used. The state stored in the state-provider cache's persistent store is deserialized and transferred; the recipient passes the data to its own cache loader, which persists it to the recipient's persistent store.
"Persistent" state transfer is enabled by setting a cache
loader's
fetchPersistentState
attribute to
true
. If multiple cache loaders are configured
in a chain, only one can have this property set to true; otherwise
you will get an exception at startup.
Persistent state transfer with a shared cache loader does not
make sense, as the same persistent store that provides the data will
just end up receiving it. Therefore, if a shared cache loader is
used, the cache will not allow a persistent state transfer even if a
cache loader has
fetchPersistentState
set to
true
.
Which of these types of state transfer is appropriate depends on the usage of the cache.
If a write-through cache loader is used, the current cache
state is fully represented by the persistent state. Data may have
been evicted from the in-memory state, but it will still be in the
persistent store. In this case, if the cache loader is not shared,
persistent state transfer is used to ensure the new cache has the
correct state. In-memory state can be transferred as well if the
desire is to have a "hot" cache -- one that has all relevant data in
memory when the cache begins providing service. (Note that the
<cacheloader><preload>
element in the
CacheLoaderConfig
configuration parameter can be used as well to
provide a "warm" or "hot" cache without requiring an in-memory state
transfer. This approach somewhat reduces the burden on the cache
instance providing state, but increases the load on the persistent
store on the recipient side.)
If a cache loader is used with passivation, the full representation of the state can only be obtained by combining the in-memory (i.e. non-passivated) and persistent (i.e. passivated) states. Therefore an in-memory state transfer is necessary. A persistent state transfer is necessary if the cache loader is not shared.
If no cache loader is used and the cache is solely a write-aside cache (i.e. one that is used to cache data that can also be found in a persistent store, e.g. a database), whether or not in-memory state should be transferred depends on whether or not a "hot" cache is desired.