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. 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

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.

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

> 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. c) We have all 3 flags: UNRELIABLE_RETURN_VALUES (= SCL + SRL), SKIP_CACHE_LOAD and SKIP_REMOTE_LOOKUP Thoughts?

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.

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

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 :)

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

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

On 20 Oct 2010, at 09:58, Sanne Grinovero wrote: > 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). I don't mind adding such syntactic sugar if we can think of a clean way (API-wise) to do this.

> 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.

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. :-)

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. :-)

cache.thisIsToDisableReturnValuesAndMakeSureYouWonTUseItAndYesTheAPIAuthorWasHackingInAPubInCaseYouWondered().remove();

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)? 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

2010/10/20 Manik Surtani <manik(a)jboss.org&gt;: > Hang on, we already have this... > > http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/main/j... Manik, I can't use Flag.SKIP_CACHE_STORE in this case as I want to write to the store ;)

I'm just not interested in loading what was eventually there before my put. This has a *huge* impact on Lucene's performance, because the put is async but the get is blocking. Not only Lucene, but any CacheStore's usage is really not async, and the performance degradation is in the order of hundreds or even thousands compared to what I get when replacing that single line with if (ctx.hasFlag(Flag.SKIP_CACHE_STORE) || ctx.hasFlag(Flag.SKIP_CACHE_LOAD)) { return false; } add a UT and this critical performance issue is solved :) Cheers, Sanne > > On 20 Oct 2010, at 09:53, Manik Surtani wrote: > >> >> 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)? >> >> 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 > > -- > 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