9 Replies Latest reply on Apr 14, 2005 12:03 PM by Jimmy Wilson

    Use of

    Jimmy Wilson Apprentice

      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?

        • 1. Re: Use of
          Bela Ban Master

          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
            Jimmy Wilson Apprentice

            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
              Jimmy Wilson Apprentice

               

              "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
                Bela Ban Master

                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
                  Jimmy Wilson Apprentice

                   

                  "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
                    Bela Ban Master

                    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
                      Jimmy Wilson Apprentice

                       

                      "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
                        Bela Ban Master

                        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
                          Jimmy Wilson Apprentice

                          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.