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

2010/10/20 Manik Surtani <manik(a)jboss.org&gt;: > > On 15 Oct 2010, at 01:05, Sanne Grinovero wrote: > >> I'd vote for A), as I would be happy enough having just SKIP_CACHE_LOAD. >> having a UNRELIABLE_RETURN_VALUES might seem a handy shortcut, but is >> not needed as long as I can use both SKIP_REMOTE_LOOKUP and >> SKIP_CACHE_LOAD, it's important that the user can tune as he wants. >> (So I'm fine with C too, just there's a flag which isn't really needed) >> >> Also I'm puzzled with the idea to have overloaded methods which return >> void, I have to admit I had it wrong once after a "quick change" for >> which the return value became important but I had forgot to remove the >> flags :) > > Fair enough, but my real issue here is to prevent a public API/interface that is too complex to use. Since we do want to extend Map, methods should be map-like and hence simple. > > Are you suggesting something like: > > cache.put2(K, V) which returns void, and perhaps internally calls cache.withFlags(SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP).put(K, V)? Yes I'd suggest something like that, but only if we can come up with a good name to not pollute the API with too many methods. This should be applied to all methods returning something, maybe we can have something like getAdvancedCache(), a method getNoreturnValuesCache() which returns a super interface having all new methods too? (to hide them in the simple Cache).

Sanne > > Cheers > Manik > > >> >> Sanne >> >> If I have SKIP_CACHE_LOAD I can control all aspects, but then of course >> 2010/10/14 Mircea Markus <mircea.markus(a)jboss.com&gt;: >>> >>> On 14 Oct 2010, at 08:46, Galder Zamarreño wrote: >>> >>>> >>>> On Oct 12, 2010, at 6:50 PM, Mircea Markus wrote: >>>> >>>>> >>>>> On 12 Oct 2010, at 15:53, Galder Zamarreño wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'd like to list the reasons why we load data from the cache store, if not present in memory, when trying to modify a k/v. >>>>>> >>>>>> So far, the most powerful one I've found is when you're dealing with cold caches and you need to return previous value. You definitely need to load first to get previous value before modifying. >>>>>> >>>>>> Now, if this is the only situation, it could be optimised by checking whether unreliableReturnValues is on or not. >>>>> +1 >>>>> What about adding a unreliable_Return_Values flag? This would skip both remote lookup and cache store (when possible). >>>> >>>> That's the key question, do we need either: >>>> >>>> a) Only a SKIP_CACHE_LOAD flag like the one suggested in http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006436.html >>>> >>>> b) A wider scope UNRELIABLE_RETURN_VALUES that encompasses both SKIP_CACHE_LOAD functionality and existing SKIP_REMOTE_LOOKUP, keeping SKIP_REMOTE_LOOKUP. >>> Tempted to go for this one, as the user obviously doesn't care about the return values if unreliableReturnvalues is set to true. >>>> >>>> c) We have all 3 flags: UNRELIABLE_RETURN_VALUES (= SCL + SRL), SKIP_CACHE_LOAD and SKIP_REMOTE_LOOKUP >>>> >>>> Thoughts? >>>> >>>>>> >>>>>> This is somehow linked with the discussion wrt https://jira.jboss.org/browse/ISPN-693 and the previous email thread for http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006436.html >>>>>> >>>>>> I can't think of any other situations right now, but it'd be interesting to know whether anyone knows other (Manik, Mircea?) >>>>>> >>>>>> Any information arising from this thread should be condensed into javadoc for loadIfNeeded method. >>>>>> >>>>>> Cheers, >>>>>> -- >>>>>> Galder Zamarreño >>>>>> Sr. Software Engineer >>>>>> Infinispan, JBoss Cache >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> infinispan-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> -- >>>> Galder Zamarreño >>>> Sr. Software Engineer >>>> Infinispan, JBoss Cache >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev