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

Dennis Reed dereed at redhat.com
Fri Nov 2 14:08:49 EDT 2012


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.  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.

> 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


More information about the infinispan-dev mailing list