On 22 November 2013 11:31, Pedro Ruivo <[email protected]> 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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
