Re: [infinispan-dev] Fixing ISPN-2384 (data loss with concurrent activation/passivation)
On Nov 2, 2012, at 7:08 PM, Dennis Reed <dereed(a)redhat.com> wrote:
On 11/02/2012 12:45 PM, Galder Zamarreño wrote:
> Ok, my suggestion below is working now, but I'm not so sure the way the
activation interceptor works is the correct one.
>
> IMO, an activation, which involves removing an entry from the cache store (and
updating the stats), should only be done when a cache entry has been retrieved from the
cache store and put into the cache, so a special get() operation.
Any operation that retrieves the entry from the cache store and puts it
into the cache should trigger the activation (remove from cache store).
But put/putAll/replace/remove do this.
^ Not precisely. These operations retrieve the value to send it back as previous value,
and even this is not mandatory, since you can skip it using Flag.IGNORE_RETURN_VALUES.
And even if they retrieve the previous value, they "don't put into the
cache".
The only operation that retrieves entry from cache and puts it into the cache per se, is
get().
The first step of each of these
retrieves the current value from the cache, to return to the caller.
> However, the activation interceptor is going beyond that by removing from the store
when put, replace, putAll, remove.
>
> Remove makes sense. The entry might not be in memory and so you want to remove it
from the store.
>
> But, put, pulAll and replace? These update the in-memory data, and don't really
see why they should remove anything from the store.
With passivation, data should *either* be in-memory, or in the cache
store. Never both.
That's the theory, what's the actual advantage of doing that? As I'm trying to
explain above, there's no real benefit of doing this, in fact it affects performance
by accessing the cache store unnecessarily (unless you have an async store).
Passivation/Activation's aim is to conserve memory but not lose data. As explained
above, you have either the potential of ending without it, or ending up with stale data
(depending on your approach), but I don't see an actual reason why the former is
'better' than the 'latter'.
> I mean, if they don't remove it from the store and the cache crashes, stale data
would be returned, unless you're a clustered cache and you'd retrieve the
in-memory data from another node. If they remove the cache store value and the cache
crashes, the data is gone, again unless it's a clustered cache. So why make an effort
removing the entry from store in these situations? It adds time in the critical path of
these operations.
>
> Thoughts?
-Dennis
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org