RE: [jbosscache-dev] Need for CacheLoader.storeState?
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