[concurrency-interest] Bug in CustomConcurrentHashMap.KeySet.intern()

Ben Manes ben_manes at yahoo.com
Tue Jun 30 15:19:22 EDT 2009


> The version there was checked in to allow discussion...

My personal preference would be a decorator-style approach rather than a god class.  Its a hard trade-off between flexibility and usability, such as the debates over the merits of the design for the Java-1.0 file streaming APIs.  I tend to prefer the flexibility and reduce the verbosity through builders and utilities, so that the programming model is still convenient.

The nice aspect of a decorator approach is that it is pluggable, though coordination is definitely harder to get right.  I support all of the features of the CCHM, as well as features that are incompatible if I based my implementations off of it.  I have the following:
- SelfPopulatingMap: single and bulk memoization, atomic refresh
- ExpirableMap: expiration support (lazy or eager) + listener
- IndexMap: Multiple keys --> value mapping
- Pluggable  data store for eviction + listener (ConcurrentMap --> no-op, unbounded, reference map, ehcache, etc)
- A builder to coordinate the construction

If it was not for the builder to hide the complexity of the coordination between decorators I would find it a hard trade-off, but the flexibility has been quite valuable.  Even then, if I had not written these prior to CCHM being available I may not have originally found the effort worthwhile.

-Ben




________________________________
From: Doug Lea <dl at cs.oswego.edu>
To: mads at renxo.com
Cc: concurrency-interest at cs.oswego.edu
Sent: Tuesday, June 30, 2009 8:08:40 AM
Subject: Re: [concurrency-interest] Bug in CustomConcurrentHashMap.KeySet.intern()

Manuel Dominguez Sarmiento wrote:
> Hi,
> 
> I found that CustomConcurrentHashMap.KeySet.intern() was the perfect fit for the object interning need we're having with a current project. 

> However, doPut() returns null when a key is first added to the map. It could be easily fixed as follows:
> 
>        public K intern(K e) {
>            K oldElement = cchm.doPut(e, e, true);
>            return (oldElement != null) ? oldElement : e;
>        }

Thanks! Fixed.

> 
> BTW, how stable is this preview release for production use? Any caveats?

Not at all stable. The version there was checked in to
allow discussion about how to support various cache-like
uses (which is among the main reasons for people to use it.)
Which led to some explorations on my part on
how to efficiently support customized eviction policies
Which has in turn led to various diversions on concurrent
(and non-concurrent) hashing that further stall getting
this in releasable form.

The Map functionality has been well-tested, but as you saw, the
auxiliary functionality hasn't.

(While I'm at it: I will be away tomorrow (July 1) through
July 14 so might not respond to mail promptly.)

-Doug
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090630/9536635c/attachment.html>


More information about the Concurrency-interest mailing list