Re: [infinispan-dev] Why is loading from store needed before storing in cache store?
On Oct 12, 2010, at 5:16 PM, Sanne Grinovero wrote:
2010/10/12 Galder Zamarreño <galder(a)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(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