Re: [infinispan-dev] Today's topic: eviction

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/o... > > 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...