4 Replies Latest reply on Sep 18, 2008 10:15 AM by manik

    trouble with invalidation replication

    shulok

      Nothing too fancy, just two simple caches, no isolation level, they work fine with REPL_SYNC and _ASYNC. If I try to do invalidation instead, the changes never get propagated. Just changing key/value pairs on a single node in the tree, but they never show up on the other three when I reference the node from there. What am I missing?

      Using the cache that comes with 4.2.2.

      Thanks,
      Thom

        • 1. Re: trouble with invalidation replication
          manik

          Well, that's what invalidation does. :-) No replication at all, just invalidates keys that have changed on remote instances.

          • 2. Re: trouble with invalidation replication
            shulok

            Thanks for the reply, Manik.

            I guess I was assuming too much, then. When the entry is invalidated, I thought the cache would see this the next time the entry is referenced, and get an updated entry from another cache in the cluster (presumably one that has a non-invalidated entry).

            If I'm not using a persistent store, how do I leverage the invalidation to find a valid entry elsewhere in the cluster? In the doc, I see a brief reference to shared cache loaders, but nothing definitive on how you would set this up when not using persistence, or how you would figure out which cache you should get a non-invalidated entry from. Any pointers here would be greatly appreciated.

            Thanks again,
            Thom

            • 3. Re: trouble with invalidation replication
              mircea.markus

               

              If I'm not using a persistent store, how do I leverage the invalidation to find a valid entry elsewhere in the cluster?

              Take a look at TcpDelegatingCacheLoader, looks like this would solve your problem.

              • 4. Re: trouble with invalidation replication
                manik

                Or even the ClusteredCacheLoader will help - the CCL lazily loads entries from its neighbours if it is needed and cannot be found locally.