cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Manes <>
Subject Re: Non-blocking DataRowStore - need help to test
Date Fri, 24 Feb 2012 07:39:38 GMT

Looking at your backport, I suspect that you compiled with JDK6 in JDK5
mode. Unfortunately this does not exclude library changes, so I suggest
using JDK5 instead. The Cayenne backport includes java.util.Deque in my
LinkedDeque implementation, but this interface was not available in JDK5.
It also is missing an override to AbstractCollection#toArray() to be safe
from concurrent modifications causing an ArrayIndexOutOfBoundsException,
which was fixed in JDK6.

Feel free to borrow from my JDK5 backport for the v1.2 release if it helps.

- Ben


On Thu, Feb 23, 2012 at 10:54 PM, Andrus Adamchik <>wrote:

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message