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

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?