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

[manik.surtani@jboss.com]

anonymous wrote : 
  | 
  | 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? 
  | 
  | 

The loader is designed to lock and load one node at a time.  And this is why it makes sense to load the entire node contents in one go, as this will then mark the node as 'loaded' and subsequent operations on the node need not check the loader for the presence of keys, etc.  Agreed that there are other ways to deal with this and that a get(fqn, key) could have been used, but this is the way it is for now.

Also, the general recommended use of the cache is to only group a few related attributes in a Node.  A Node isn't designed to hold a large number of attributes.  This minimises the 'pain' of a get(Fqn) call.

I would not recommend rewriting the CacheLoaderInterceptor at this stage - if anything, I'd say put more effort into Infinispan instead, where similar functionality will be more efficient.


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

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