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

Wed Oct 20 14:32:08 EDT 2010

On 20 Oct 2010, at 19:15, Sanne Grinovero wrote:

> 2010/10/20 Manik Surtani <manik at jboss.org>:
>> Hang on, we already have this...
>> 
>> http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/main/java/org/infinispan/interceptors/CacheLoaderInterceptor.java?r=2525#l124
> 
> Manik, I can't use Flag.SKIP_CACHE_STORE in this case as I want to
> write to the store ;)

Ok, makes sense.

> 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 at jboss.com>:
>>>>> 
>>>>> 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 at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> infinispan-dev mailing list
>>>>>>> infinispan-dev at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org