[infinispan-dev] fixing eviction with transactions (critical for Hibernate Search)

[Sanne Grinovero]

2011/6/8 Manik Surtani <manik at jboss.org>:
>
> On 8 Jun 2011, at 16:24, Sanne Grinovero wrote:
>
>> I was mentioning passivation was enabled as debugging I saw it was
>> going to invoke to the passivator,
>> but I just realized that passivation was actually disabled in my configuration.
>> So one thing I'm solving now, is that we don't need to lock if the
>> passivator is disabled, as we're not going to do any operation with
>> the lock held, besides potentially invoking user listeners.
>> So this affects the 2nd level cache as well, as the bug kicks in
>> regardless of the passivation being enabled).
>>
>> Some findings about this lock, after talking with Vladimir yesterday on irc:
>>
>> we realized that the lock is actually acquired *after* it was evicted
>> from the container;
>> so if the mission of this lock was to protect readers from reading the
>> non-existing value, then we should acquire it before it's actually
>> evicted; currently there's a smallish race condition possible, in
>> which the value has been evicted but not stored yet; during the proper
>> store operation which is likely the slowest part the lock is owned so
>> this might prevent a get with locks to not find the value anywhere.
>>
>> So for this case maybe having the lock is a good idea, but could
>> anybody confirm that having the lock would prevent an inconsistent
>> read?
>
> Is this lock good enough here?  There is still a race between evicting from the data container and acquiring the lock that a thread may attempt a read and find nothing.
>
> But even then this doesn't really help since this is a write lock we are talking about.  Concurrent readers will not acquire a write (or even read) lock.
>
> The correct approach really should be:
>
> 1) Passivate entry to a CacheStore
> 2) Evict entry from data container
>
> with no need for a lock.  This would mean the BoundedCHM would have a handle on the Passivator.

Yes, we're on the same channel now. That's exactly what I meant
yesterday on IRC when mentioning the BoundedCHM, and what I meant
above with "we should acquire it before it's actually evicted".
But this issue is getting complex, I've split it in 4 different
problems and I'm going to solve the first three soon, the BoundedCHM
is the fourth and I'm not sure I'll fix that today.

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
>