[jbosscache-dev] JBoss Cache 2.0.0.ALPHA status

[Manik Surtani]

If we're implementing store/loadState in an AbstractCacheLoader  
(which uses gets/puts anyway), then why not move this code into the  
interceptor and ditch the store/loadState methods from the  
CacheLoader interface?

Hmm, trying to think of why this may not be a good thing ...


--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 12 Sep 2006, at 14:25, Vladimir Blagojevic wrote:

>
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik at jboss.org]
>> Sent: Tuesday, September 12, 2006 4:21 AM
>> To: Bela Ban
>> Cc: Vladimir Blagojevic; jbosscache-dev at lists.jboss.org
>> Subject: Re: [jbosscache-dev] JBoss Cache 2.0.0.ALPHA status
>
>> 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?
>>
>
> I am not sure how Bela envisioned that cacheloader can be  
> refactored to
> interceptor but I suppose it is possible. What we talked about was
> having
> generic cacheloader storeState Method in AbstractCacheLoader.  
> StoreState
>
> can be generic since we simply read NodeData objects from stream and
> call
> put on underlying cacheloader. I suppose we can also make generic
> loadState
> that only relies on cacheloader's get method and a recursive call.  
> That
> would
> be cool. But yes cacheloaders are getting simpler and easier to
> implement :)