-
1. Re: Use of
belaban Apr 6, 2005 3:41 PM (in response to jiwils)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
-
2. Re: Use of Fetch Flags for Cache Loaders
jiwils Apr 7, 2005 9:42 AM (in response to 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.
-
3. Re: Use of Fetch Flags for Cache Loaders
jiwils Apr 9, 2005 12:02 AM (in response to 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. -
4. Re: Use of
belaban Apr 11, 2005 4:28 AM (in response to 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 -
5. Re: Use of
jiwils Apr 13, 2005 10:40 AM (in response to jiwils)"bela@jboss.com" wrote:
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? -
6. Re: Use of
belaban Apr 13, 2005 2:04 PM (in response to 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.
-
7. Re: Use of
jiwils Apr 13, 2005 4:45 PM (in response to jiwils)"bela@jboss.com" wrote:
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? -
8. Re: Use of
belaban Apr 14, 2005 1:28 AM (in response to jiwils)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 -
9. Re: Use of
jiwils Apr 14, 2005 12:03 PM (in response to 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.