RE: [jbosscache-dev] Need for CacheLoader.storeState?
by Brian Stansberry
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(a)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(a)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(a)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(a)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
19 years, 1 month
RE: [jbosscache-dev] Need for CacheLoader.storeState?
by Vladimir Blagojevic
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(a)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(a)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
>
>
19 years, 1 month
Some new Cache usage questions
by Ben Wang
Manik,
While trying to use the new API in PojoCache, I have found that I need to:
1. To check if a attribute exist, I need to do:
cache_.getRoot().getChild(fqn_).getData().values().contains(PojoInstance.KEY)
2. And then, I need to do a lot of cache_.getRoot().getChild(fqn).put(map)
So looks like I need to write a wrapper layer just to provide straight api for:
Cache_.exists(fqn, key)
And
Cache_.put(fqn, map)
If this is rare case, then I will bite the bullet. But if it is a common one, then that really begs the question whether we should provide additional apis or not?
Thanks,
-Ben
19 years, 1 month
RE: [jbosscache-dev] Need for CacheLoader.storeState?
by Vladimir Blagojevic
Good stuff.
No ideas yet about improving transfer format (at least from me). Thought
of hand serializing fqns as strings but now fqns can have any object as
path elements so that's out. During state transfer operation inevitable
put and get from underlying cacheloader are much more expensive and I am
not sure if it will make much difference in the end?
> -----Original Message-----
> From: Bela Ban
> Sent: Thursday, August 31, 2006 5:47 PM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)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(a)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
>
>
19 years, 1 month
Need for CacheLoader.storeState?
by Vladimir Blagojevic
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
19 years, 1 month
