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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
