Re: [infinispan-dev] Passivation and BCHM WAS: fixing eviction with transactions (critical for Hibernate Search)
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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org