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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 12 Sep 2006, at 14:25, Vladimir Blagojevic wrote:
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Tuesday, September 12, 2006 4:21 AM
> To: Bela Ban
> Cc: Vladimir Blagojevic; jbosscache-dev(a)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 :)