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

Manik Surtani manik at jboss.org
Wed Jun 8 12:02:56 EDT 2011


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.

Cheers
Manik

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org






More information about the infinispan-dev mailing list