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

[Galder Zamarreño]

On Oct 12, 2010, at 5:16 PM, Sanne Grinovero wrote:

> 2010/10/12 Galder Zamarreño <galder at redhat.com>:
>> 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.
> 
> As author of both the issue and the other thread, you know I'm a
> strong supporter to prevent this when not needed :)
> 
> Still there are other cases, almost all atomic operations of ConcurrentMap:
> 
> pufIfAbsent( key, value )
> replace( key, value )
> replace( key, oldValue, newValue )
> remove( key, value )
> 
> the non-concurrent remove:
> 
> remove( key )

Yup

> 
> these might be able to answer without loading, but still should have a
> look in the store:
> containsKey
> containsValue
> size

Well, containsKey is a get() at the end of the day and if present in memory, it won't check the store. Why look again regardless?

containsValue not supported.

Currently size only takes into account size of cache in memory. This is actually something we haven't specified this in detail, but we do say:

* Other methods such as {@link #size()} provide an approximation-only, and should not be relied on for an accurate picture
 * as to the size of the entire, distributed cache.  Remote nodes are <i>not</i> queried and in-fly transactions are not
 * taken into account, even if {@link #size()} is invoked from within such a transaction.

We should probably specify whether cache store contents are taken into account or not. I'd vote for no.

> 
> and all the overloaded versions having additional timeout parameters
> or Async options.
> 
> Actually also some of the atomic methods, like replace and
> putIfAbsent, could perhaps be implemented at store level without
> loading the value in memory.

Yeah, assuming the store had some CAS-like op available.

> 
> Cheers,
> Sanne
> 
>> 
>> 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