[jbosscache-dev] Need for CacheLoader.storeState?

[Bela Ban]

Okay. We can actually say that FQNs can only have strings as components, 
which is a requirement for some cache loaders anyway (JDBC for instance)

Vladimir Blagojevic wrote:
> 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 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
>
>   

-- 
Bela Ban
Lead JGroups / Manager JBoss Clustering Group
JBoss - a division of Red Hat