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

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(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev