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

[Sanne Grinovero]

2011/6/10 Manik Surtani <manik at jboss.org>:
>
> On 10 Jun 2011, at 14:18, Sanne Grinovero wrote:
>
>> It looks as a good improvement, especially as we remove the locking,
>> but I still have some doubts:
>>
>> 1) as the passivation happens in the eviction thread, is that going to
>> be fast enough or hindering the eviction performance? especially with
>> LIRS, being this the user thread it means that put operations suffer a
>> mayor performance hit (for async caheloaders, see next point). Well
>> this was the case already, I guess.
>
> Yes, this is already the case.
>
>> 2) with async stores, the issue is back. The value is not going to be
>> found while it's "in flight" in the async storage queue; so unless you
>> want to avoid supporting it for now, the actual removal from the
>> container should be performed from the async cache loader code.
>
> Ugh - yes, I agree.  But I hate the way the mixing of concerns is starting to look.  :-(
>
>> So it looks like that - when passivation is enabled - the proper way
>> to implement this is to use the eviction policy only to identify
>> what's going to be removed from the container, but not to actually
>> remove it.
>>
>> I'd still focus on having the best performance possible for the case
>> in which passivation is not enabled, that looks like the "performance
>> needing" setup, or maybe we need separate eviction strategies fro when
>> passivation is enabled.
>
> Probably true.
>
>> 3) so every time we evict an entry, we write it to the store.. I guess
>> that leads to re-write quite often values which are already in the
>> store, and for which there's no need to store again. I think this
>> argument came up before, but we didn't want to track an additional
>> boolean to keep the memory need low. Still when we're using it as a
>> cache with eviction rules in place, it seems to me that overall
>> performance would be better by avoiding more writes at the cost of
>> being able to store some less entries in memory.
>
> 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 ? :)

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.

Cheers,
Sanne

>
> Cheers
> Manik
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>