[jboss-dev-forums] [Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers
akluge
do-not-reply at jboss.com
Sun Jun 7 23:12:58 EDT 2009
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
More information about the jboss-dev-forums
mailing list