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

[Sanne Grinovero]

2011/6/24 Vladimir Blagojevic <vblagoje at redhat.com>:
> 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?

That was my impression as well, it needs to be in sync or otherwise
the value is temporarily lost.

>
> 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.

+1

>
> Vladimir
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>