3 Replies Latest reply on Nov 22, 2004 3:47 PM by norbert

    TreeCacheListener

    chucklan

      What is the extent of the locking performed on the TreeCache instance with the methods of a TreeCacheListener instance?

      -Chuck

        • 1. Re: YACL  (Yet Another CacheLoader) question
          norbert

          Is there a specific reason why my posting was truncated?
          Is there something wrong with the forum code?

          /Erik

          "nine_mirrors" wrote:
          Howdy all,

          I'm (still) implementing a cache loader and trying to get a feel for how it works.
          I'm wondering about TreeCache.get(Fqn). It does not seem to call CacheLoader.get(Fqn) (which it should in my opinion).

          My code:

          TreeCache cache = new TreeCache();
          .
          .
          Node node = cache.get(new Fqn("top_node");

          I trace the excution to TreeCache.findNode() and to this snippet:

          // try CacheLoader if node is not in cache
          if(child_node == null && cache_loader != null) {
          try {
          if(cache_loader.exists(fqn)) {
          child_node=n.createChild(child_name, tmp_fqn, n, UNINITIALIZED, null);
          notifyNodeLoaded(tmp_fqn);
          }
          }


          • 2. Re: TreeCacheListener
            belaban

            Same as with the regular methods.

            • 3. 3852220
              chucklan

              In your javadoc for TreeCacheListener, it states:

              public interface TreeCacheListener
              
              Callbacks for various events regarding TreeCache. Implementers should avoid performing long running actions, as this blocks the cache. If you have to do so, please start a new thread.
              


              To what extent does this block the cache? Is the blocking at the instance level of the cache?

              Thanks,

              -Chuck