7 Replies Latest reply on Nov 3, 2005 3:24 PM by belaban

    Custom cacheloader ignores get method implementation?

    sean_gildea

      We have created our own custom cacheloader implementing the CacheLoader interface.

      Everything is configured fine and works except for the fact that when our treeCache object calls get, and cannot find the object in the cache, it does not call our implementation of get in our cacheloader.

      To isolate the problem, we implemented the put method in our custom cacheloader and called treeCache.put, which actually worked fine, calling our custom cacheloader implementation.

      Is there is a restriction on implementing the get method of a custom cacheloader?

      Thanks,
      Sean Gildea

        • 1. Re: Custom cacheloader ignores get method implementation?
          belaban

          I'm calling exists() first, then get() based on the result. Did you implement exists() correctly ?

          This inefficiency will be fixed in 1.3

          • 2. Re: Custom cacheloader ignores get method implementation?
            gwwallace

            A piece of further information.

            We have a hierarchy /a/b which is empty to start with.

            At cache startup we start try to load in /a/b/c, /a/b/d, /a/b/e etc

            If we call cache.exists(Fqn) the cache loader gets the exists(Fqn) call and returns true.

            If we then call cache.get(Fqn) the cache loader never gets the equivalent get call. however if we call
            cache.get(Fqn, Object) the cacheloader will get the call and everything works fine.

            Any ideas ?

            • 3. Re: Custom cacheloader ignores get method implementation?
              belaban

               

              "gwwallace" wrote:
              A piece of further information.

              We have a hierarchy /a/b which is empty to start with.

              At cache startup we start try to load in /a/b/c, /a/b/d, /a/b/e etc

              If we call cache.exists(Fqn) the cache loader gets the exists(Fqn) call and returns true.


              No, this is incorrect ! The exists() method does not acquire any locks, and it does not call the CacheLoader's exists() methods.


              If we then call cache.get(Fqn) the cache loader never gets the equivalent get call. however if we call
              cache.get(Fqn, Object) the cacheloader will get the call and everything works fine.


              I just checked the code: both get() calls should call the equivalent exists() on the CacheLoader, then the get() on the CacheLoader.

              Compare your CacheLoader to FileCacheLoader to see what FileCacheLoader is doing differently.

              You may also want to create a unit test a la FileCacheLoaderTest, which runs all CacheLoader unit tests against your implementation.

              • 4. Re: Custom cacheloader ignores get method implementation?
                gwwallace

                Ok. I generated a stack dump from inside cacheloader.exists() to see where it got called from....I was wrong :) it is the get call that triggers it.

                However - looking at the source for CacheLoaderInterceptor it looks like
                the cacheloader only gets called if load_attributes is set to true.


                But anyway - i guess the real question is -

                if i want to preload a bunch of data into the cache at startup - whats the recommended way of doing it, given that cache.get(Fqn) doesnt actually call the cacheloader to get data.

                • 5. Re: Custom cacheloader ignores get method implementation?
                  belaban

                  Prelolading can be done in 2 ways:
                  #1 Use the attr in the XML file (read the docs regarding this)

                  #2 Call TreeCache.load(Fqn)

                  • 6. Re: Custom cacheloader ignores get method implementation?
                    jimcross

                    I'm basically having the same problem.

                    During get(), the exists is called on CacheLoader but not the actually get() so the object is never loaded unless it was preloaded. During preload, the logic is to call exists then get.

                    Even if this worked correctly, the way it works would be problematic.

                    Let's say that there is a large amount of overhead in determining something exists - for example, we have to actually load it.

                    If we have to load it to be able to say it exists, we will then have to load it again to actually return it. A double load for every object.

                    Am I missing something with this?

                    • 7. Re: Custom cacheloader ignores get method implementation?
                      belaban