[infinispan-dev] Why is loading from store needed before storing in cache store?

"이희승 (Trustin Lee)" trustin at gmail.com
Thu Oct 21 04:42:59 EDT 2010


Manik Surtani wrote:
> On 21 Oct 2010, at 07:06, 이희승 (Trustin Lee) wrote:
> 
> <SNIP />
> 
>>> better names?
>>>
>>> cache.asVoid().remove();
>>> cache.disableFetch().remove();
>>> cache.thisIsToDisableReturnValuesAndMakeSureYouWonTUseItAndYesTheAPIAuthorWasHackingInAPubInCaseYouWondered().remove();
>> To avoid the overhead of setting frequently used flags, I'd suggest
>> these flag methods to return a decorated or duplicated Cache instance
>> with updated default flags.
>>
>> Cache myCache;
>> myCache = cache.withFlags(SKIP_REMOTE_LOOKUP, SKIP_CACHE_LOAD, ...);
>> myCache.remove();
>>
>> A user could even have multiple Cache instances that decorates the same
>> cache with different flags.
>>
>> But wait, don't we already have a similar one in AdvancedCache?  It
>> seems stateful unlike my suggestion though.  If it can be stateless like
>> I suggested, I think it could be moved up to Cache.
> 
> 
> Well the whole purpose of making it stateful is to enable builder-style application of flags to any and all Cache API calls.

I misphrased.  I was trying to say the current implementation allows
changing the flags of an existing Cache and I prefer not to allow that
because it could change the Cache behavior and cause thread safety issue
when a user changes the flags on and off in multiple threads.

But.. I've just realized that withFlags() uses a ThreadLocal to store
the flags.  Sorry about the premature posting!  :)

> Sanne's approach does make sense, for certain frequently-used flag patterns provide a helper API which is essentially cache-like, and makes calls to the cache with appropriate flags each time.  And in the case of suppressing return values, this makes the most sense since this can be modelled in the API via method return types. 
> 
> This helper API can be cached too, e.g.:
> 
> NoReturnCache nrc = cache.asNoReturnCache();
> nrc.put(k, v); // returns void, and adds relevant flags to cache
> 
> The tough bit is, what do you call this?  ;)

I love the idea of returning NoReturnCache instead of returning Cache
with unexpected behavior.  Perhaps we could even extract the async
operations and do the same:

   AsyncCache ac = cache.asAsync();
   NotifyingFuture<..> f = ac.put(k, v);

But, what if a user want the combination of NoReturnCache and AsyncCache?

Name?  We should brainstorm a little bit more. :-)

-- 
Trustin Lee - http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 290 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101021/4fb8e3f5/attachment.bin 


More information about the infinispan-dev mailing list