[jboss-dev-forums] [Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers

[akluge]

Hi,

    The test setup is using a one cache (L1) connected to a separate
  cache (L2) with  TcpDelegatingCacheLoader. The second cache is
  of course running with a TcpCacheServer.

    When I refer to a cache miss, I am speaking of performing a get for
  key that does not exist in the L1 cache. The get request is intercepted,
  as it should be, by the  CacheLoaderInterceptor.


   The visitGetKeyValueCommand method is invoked, and it has the full
  get command (most importantly, it has the Fqn and the key). The
  Fqn and the key are passed to the loadIfNeeded method, along with
  false for the allKeys parameter. So far, everything looks reasonable.

   However, the loadIfNeeded method does not directly use the allKeys
  parmater, it simply passes it on to the mustLoad method, and doesn't
  concern us any further.

   As expected, mustLoad returns true if the key is not in the cache,
  and the loadIfNeeded method then loads the entire node from the loader,
  which in this case results in the entire node being loaded across the
 network. This request is delegated to the relevant loader,  in this case a
 TcpDelegatingCacheLoader.

   This is clearly the way that JBossCache is designed, as the
  CacheLoader interface defines only a get(Fqn) method, and no
  get(Fqn, key). The question is, why was this design decision made?
  Is there something that depends on this behavior?

   This really hurts in terms of scalability. I an looking at replacing
  the interceptor and the loader eventually so that a get does not attempt
  to load an entire segment of the cache as it does now.

                                            Thanks,
                                                        Alex

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4235869#4235869

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4235869