[infinispan-dev] Fixing ISPN-2384 (data loss with concurrent activation/passivation)

[Galder Zamarreño]

On Nov 2, 2012, at 7:08 PM, Dennis Reed <dereed at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org