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

Sanne Grinovero sanne.grinovero at gmail.com
Tue Oct 26 04:57:37 EDT 2010


2010/10/21 "이희승 (Trustin Lee)" <trustin at gmail.com>:
> 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?

Yes that would be nice, but we can maintain two interfaces and their
combination, but it wouldn't be maintainable if more similar API
changes would appear later on.
I don't foresee anything different than "async", "noreturn" and
"asyncNoreturn"; would it be possible for more to be needed in future?

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

I like the shorter names, assuming it's clear enough:

cache.async().noreturn().put()

BTW, should they be able to be reverted?
cache.async().noreturn().put()
cache.noreturn().async().put()
I guess they should.. again this is not going to fly if we foresee
more of this kind of Flags (the kind of flags which affect the return
type)

Cheers,
Sanne



More information about the infinispan-dev mailing list