[infinispan-dev] Passivation and BCHM WAS: fixing eviction with transactions (critical for Hibernate Search)

[Manik Surtani]

On 10 Jun 2011, at 14:44, Sanne Grinovero wrote:

>> With passivation enabled, the entry is only written to the store when removed from memory.  And when activating (store -> memory) it is removed from the store.  So you wouldn't really write twice to the store.
> 
> Thanks, with that you answered an unasked question I had.
> So, should we check for race conditions while reading too, that the
> entry disappears from a shared cacheloader before all active owners
> have it in the container ? :)

The ActivationInterceptor removes it from the cache store after it is written to the data container.

> Anyway these thoughts boil down to one question: what's the use case?
> Why should anybody use this? It looks to me that passivation=false &
> async cache loader is always superior, and keeps us with a nice and
> clean evict-from-memory-only problem, which can be performed
> efficiently.

A couple of things.  With passivation on, you have synchronous write to disk when something is removed from memory, as well as the performance benefit that every time you update the entry in memory you don't write to disk (only when evicted).

With async loader, you still write to disk with every put (cost mitigated because it is async and because you can coalesce changes) but the write will still be async, which means a subsequent read after eviction from memory may not be found if the entry is still in the async queue.

Cheers
Manik

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org