[jbosscache-dev] Need for CacheLoader.storeState?

Brian Stansberry brian.stansberry at jboss.com
Fri Sep 1 14:00:35 EDT 2006


AbstractCacheLoader is just meant to be a helpful refactoring, yes?

So, can we do this:

public void put(Fqn fqn, Map map)
{
  put(fqn, map, true); // or false if that is the right default
}

public abstract void put(Fqn fqn, Map map, boolean erase);

And then change the cache loaders we wrote to implement the method with
the boolean?

jbosscache-dev-bounces at lists.jboss.org wrote:
> Hey,
> 
> There is an interesting quirk with this whole thing. In
> brief, storeState implementation of AbstractCacheLoader after
> it reads NodeData from inputstream it writes it to cache like this:
> 
> if (nd.attrs != null)
> 	put(fqn, nd.attrs, true);  //void put(Fqn name, Map
> attributes,boolean erase) throws Exception; else
>        put(fqn, null); // void put(Fqn name, Map attributes) throws
> Exception; 
> 
> As you know true parameter in put clears the existing map.
> However,the trick is that CacheLoader only exposes:
> 
> void put(Fqn name, Map attributes) throws Exception;
> 
> and not
> 
> void put(Fqn name, Map attributes,boolean erase) throws Exception;
> 
> So I cannot move storeState up to AbstractCacheLoader unless
> we expose put with erase.
> 
> 
> It took me like two hours to figure this out since compiler
> did not complain - it automatically boxed boolean parameter
> and linked invocation of put(fqn, nd.attrs, true); to method
> Object put(Fqn name, Object key, Object value) throws Exception;
> 
> I did a very simple change of moving storeState to
> AbstractCacheLoader and tests started to fail. I thought I
> was halucinating.
> 
> So what do we do?
> 
> 
>> -----Original Message-----
>> From: Bela Ban
>> Sent: Thursday, August 31, 2006 5:47 PM
>> To: Vladimir Blagojevic
>> Cc: jbosscache-dev at lists.jboss.org
>> Subject: Re: [jbosscache-dev] Need for CacheLoader.storeState?
>> 
>> Absolutely, I had that idea when I wrote the cache loader interface,
>> but never saw it through... +1 for sure, this takes a lot of pain
>> out of the implementations. 
>> 
>> Are you guys thinking about a more efficient transfer format, or is
>> NodeData still the awy to go ?
>> 
>> Vladimir Blagojevic wrote:
>>> Hi,
>>> 
>>> After we resolve streaming format incompatible cacheloader
>>> implementations [1][2], and as we continue to follow newly agreed
>>> streaming state transfer format - we do not have to require
>>> cacheloader implementers to write their own implementations of
>>> storeEntireState and storeState !
>>> 
>>> CacheLoader.storeEntireState and CacheLoader.storeState are always
>>> the same. They read NodeData objects from stream and call put with
>>> underlying cacheloader. Put method does the cacheloader specific
>>> stuff. 
>>> 
>>> We can possibly keep storeEntireState and storeState in CacheLoader
>>> API but move default implementations to AbstractCacheLoader. Any
>>> suggestions or opinions? 
>>> 
>>> 
>>> [1] http://jira.jboss.com/jira/browse/JBCACHE-748
>>> [2] http://jira.jboss.com/jira/browse/JBCACHE-749
>>> 
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>> 
>>> 
>> 
>> --
>> Bela Ban
>> Lead JGroups / Manager JBoss Clustering Group JBoss - a division of
>> Red Hat 
>> 
>> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev



Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry




More information about the jbosscache-dev mailing list