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

Sanne Grinovero sanne.grinovero at gmail.com
Tue Oct 12 11:16:21 EDT 2010


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 )

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

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.

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
>



More information about the infinispan-dev mailing list