Use of

[jiwils]

My interpretation of the CacheLoaderFetchPersistentState attribute is that when a cache instance is joins a cluster of extant caches, the cache loader will fetch the "in memory" state of the cache and then persist it. Of course this only happens if the cache loader is unshared (and mine is). However, this does not appear to happen. The "in memory" cache for the cache instance with the attached cache loader does get the transient state, but apparently nothing about that state is written to disk. Is there a way to cause this to happen? Otherwise, if a cache instance with a cache loader fails, how can recreate that persisted state?

[belaban]

No, CacheLoaderFetchPersistentState fetches the entire 'persistent' state (e.g. the contents of a table, or filesystem dir) and inserts it into the local cache loader

[jiwils]

Oops! I meant to ask about the CacheLoaderFetchTransientState attribute not the CacheLoaderFetchPersistentState attribute. I must have copy/pasted the wrong thing. When using CacheLoaderFetchTransientState set to true, the cache loader never has anything added to it when joining an extant cluster of caches, and it was this behavior to which I was referring.

[jiwils]

"jiwils" wrote:
Oops! I meant to ask about the CacheLoaderFetchTransientState attribute not the CacheLoaderFetchPersistentState attribute. I must have copy/pasted the wrong thing. When using CacheLoaderFetchTransientState set to true, the cache loader never has anything added to it when joining an extant cluster of caches, and it was this behavior to which I was referring.

So, is it correct behavior for a cache with a cache loader newly introduced to a cluster with the transient attribute set to true to *not* persist the transient state? That is the behavior I am experiencing.

[belaban]

Yes, it will *not* persist anything, unless you
(a) enable CacheLoaderFetchPersistentState and
(b) have a CacheLoader.

We're talking pure in-memory state transfer

[jiwils]

Yes, it will *not* persist anything, unless you
(a) enable CacheLoaderFetchPersistentState and
(b) have a CacheLoader.

We're talking pure in-memory state transfer

So would an enhancement that allowed a cache with a unshared cache loader to persist transient state upon joining a cache cluster be a feasible idea/alternative? Do the example changes I sent make sense in that regard?

[belaban]

I'm not sure I see the use case, because a CacheLoader usually sits on a large persistent store, so unless those (unshared) stores would be in-sync, I don't see the point of this.

[jiwils]

I'm not sure I see the use case, because a CacheLoader usually sits on a large persistent store, so unless those (unshared) stores would be in-sync, I don't see the point of this.

This is exactly the use case I have (I think). My cache is not used to cache datastore data, my datastore is used to persist the cache. It is only for backup purposes (in case of total cache failure), so it duplicates the transient cache state (if more than one loader existed, they would be in synch). Furthermore, there is no eviction. This is very close to the use case described in the TreeCache documentation surrounding cache loader figure 4.2:

This is a similar case as the previous one, but here only one node in the cluster interacts with a backend store via its CacheLoader. All other nodes perform in-memory replication. A use case for this is HTTP session replication, where all nodes replicate sessions in-memory, and - in addition - one node saves the sessions to a persistent backend store.

While I am not doing HTTP session replication, I think the same use case applies. I have a single, unshared cache loader in the cluster, so that if I lose all of the "in memory" cache instances, I still have a backup of the state that I can use to recreate the "in memory" cache. The issue arises when the cache loader node is down (involuntarily) and some changes have occurred to the still running, memory-only cache instances. I need to be able to repersist the cache state to disk (by starting a new cache loader instance) so that I can continue to have a backup. Even in the HTTP session replication situation related above, wouldn't this be a good feature to have?

[belaban]

Okay, I see what you want. However, this doesn't work with eviction, e.g. node-a evicted some elements, node-b comes up, fetches the in-memory state of node-a and persists it into its own CacheLoader, and you have inconsistent states.

Wjy don't you create a JIRA feature request with this thread attached (the relevant parts), so we can look into adding this feature in 1.2.4 or 1.3 ?
I don't want to address this in 1.2.3

[jiwils]

http://jira.jboss.com/jira/browse/JBCACHE-131

Attached to it is a modified version of TreeCache based on the latest CVS revision that provides the behavior described in this thread.