Hi Ben, Thanks for dropping a note :) It is very good to know that CLHM is a supported and evolving technology.
There's no dependency on Guava, so it felt like internalizing ConcurrentLinkedHashMap was the right thing at the moment. This is not a final decision, especially since we'll be working on unifying the 2 caches (object cache and query result cache) at some point. But for now it felt like the easiest way to get things going without exposing the internals to the end users. With your message contributing to my confidence in CLHM, the most important remaining question for us right now is whether the removal of synchronizations spanning multiple get/put operations will cause any undesired effects. But this is purely a Cayenne thing, untreated to the underlying cache, so we'll have to deal with that on our own. Thanks! Andrus On Feb 24, 2012, at 12:05 AM, Benjamin Manes wrote: > Hi, > I'm the author of CLHM, brought to you by a friendly Google alert. :) > > If Cayenne is currently using Guava, then there won't be a dependency > increase. I helped rearchitect MapMaker and design its replacement, > CacheBuilder, which are based on CLHM's algorithms. This is a more > feature-rich implementation with the support of a team at Google (whereas > CLHM is my weekend project). We also fixed my mistake of only weighing by > value, since I hadn't realized how popular memory-based weighing would be (I > was trying to avoid unbounded collections as values). > > Technically CLHM provides more concurrency than CacheBuilder by not relying > on segment locks and later using a lock-free ring buffer. These will be an > advantage when it is backed by JDK8's new CHM (see ConcurrentHashMapV8) or > Cliff Click's NBHM. A JSR-166 implementation will be a marriage of CHMv8, > CLHM, and CacheBuilder. > > CLHM is back-ported to JDK5 on every release, so you'll find the JDK5 source > under /tags. I do development on /trunk assuming JDK6. > > Feel free to file issues against CLHM (or Guava) if you'd like enhancements > to either. Both are used in large production environments. > > Cheers, > Ben
