[infinispan-dev] Today's topic: eviction

[Sanne Grinovero]

On 22 November 2013 11:31, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>
> On 11/21/2013 10:08 PM, Sanne Grinovero wrote:
>> Hi Pedro,
>> great analysis.
>> Conceptually I agree, and since I'm not too familiar with the core
>> code, I actually expected this to be the case as we discussed the
>> approach when we first discussed the single-lock-owner pattern.
>>
>> More specifically on the DataContainer: I don't think you should lock
>> the segment, you need to lock the key entry only as the CacheStore
>> could be quite slow so that is a "long" lock at least relatively to
>> normal usage.
>
> Agree with you. I based my solution on the current
> BoundConcurrentHashMap [1] implementation that uses locks per segment.
> Also, the eviction is kicked inside this locks so we already have a
> "long" lock to write the entry in the cache writer.
>
> [1] Segment.put():
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/BoundedConcurrentHashMap.java#L1554
>
>>
>> This should NOT be the normal key lock however, as you might remember
>> I'm since long time advocating that there needs to be a split in
>> logical "lock" as the user sees it (and as used by transactions) vs
>> the locks we use internally to keep our very own data structure
>> consistency.
>>
>> It's trivial to apply if you use
>>
>>     EquivalentConcurrentHashMapV8.computeIfAbsent(K, Fun<? super K, ? extends V>)
>
> This is a great idea :)
>
> The EquivalentConcurrentHashMapV8 will solve the problem for unbounded
> data container but we still have to do more work with the bounded data
> container I'm afraid...

Do we still need to support the non-V8 implementations?
Clearly there are cases in which we need it to be available:
 org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer<L>
refers explicitly to EquivalentConcurrentHashMapV8

Sanne