[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Bela Ban]

To make our lives easier. I don't believe in providing all the 
functionality in the world, if 1 cache loader (e.g. TCP) will do. Is 
anyone using RPC or RMI cache loaders ? Your call...

Manik Surtani wrote:
> On 11 Sep 2006, at 21:59, Bela Ban wrote:
>
>>
>>
>> Vladimir Blagojevic wrote:
>>> I made TcpCacheLoader test pass but tcpcacheloader will not propagate
>>> load/store. This was the case even before I made the cacheloader 
>>> change.
>>> Similar situation is with rpc and rmi loaders and we have to figure out
>>> what to do there.
>>
>> Should we dump (= move to the obsolete dir) Rpc and RMI cache loaders 
>> ? I would at least ask in the forums whether anyone is using these. 
>> That way, fewer options to support.
>>
>>
>
>
> Do we dump them purely to make our lives easier, or because the use 
> case is obsolete?  Do we have reason to believe the latter?
>
>
>>> It would be great if someone familiar with bdjecacheloader can make it
>>> compatible with streaming format.
>>
>> It was written by a Sleepycat employee first. Now, if we follow 
>> through with Vladimir's recent thoughts, we can pull most of the 
>> streaming (and cache loader handling) logic into the cache 
>> loader/store interceptors, so cache loader impls themselves will be 
>> trivial. Thus, we would only have to change code in one place. 
>> Suggestions ?
>>
>
> I agree with this - but just to re-iterate, the only improvement here 
> is formalising the format of state stored in the loaders, am I correct?
>
> Or is it more like removing load/store state methods on the cache 
> loader interface altogether and let the interceptors deal with this 
> using loader.put()/get() calls - since this is what happens internally 
> (within the cloader impl) anyway?
>
>
>

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