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

[Vladimir Blagojevic]

Manik & Sanne see below.
On 11-06-10 9:33 AM, Manik Surtani wrote:
> 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.

I reviewed BCHM eviction hooks and how passivation is done and it seems 
to me that we write synchronously to cache store from BCHM eviction 
callbacks. Would you please confirm?

Having an order of magnitude slower passivate call during BCHM eviction 
callback *while* lock is held on BCHM segment is obviously going to make 
a big impact on performance for the worse. We have to find another solution.

Vladimir