Concurrent MultiMap versions

[GoogleCodeExporter]

MultiMap is great. However, in the place I replaced lots of annoying code 
with a multimap, I used a ConcurrentMap. Now I have to rewrite all code to 
use external synchronization, possibly inflicting performance. Thus, a 
Concurrent version of MultiMap would be great. 

I read in another issue that there are such code being worked on - how is 
that doing? I assume this is utterly known, but the original 
ConcurrentHashMap is public domain, so possibly the main concurrency-logic 
could be ripped?

Original issue reported on code.google.com by stolsvik on 1 Apr 2009 at 9:47

[GoogleCodeExporter]

.. also, read-only/unmodifiable views of these maps would be nice.

Original comment by stolsvik on 1 Apr 2009 at 9:53

[GoogleCodeExporter]

The Multimaps.synchronized*Multimap and Multimaps.unmodifiable*Multimap methods 
create synchronized or unmodifiable multimaps. Those provide most of the 
functionality you're asking for.

The library does lack a ConcurrentMultimap class analogous to ConcurrentMap or 
ConcurrentMultiset. I actually wrote one, but its code quality and usefulness 
aren't 
strong enough to justify including it in the open-source library.

Original comment by jared.l....@gmail.com on 1 Apr 2009 at 12:30

[GoogleCodeExporter]

ah, hadn't found those methods yet (I've just started using GCollections). 
Thanks. 

I'll still be looking forward for the Concurrent versions..! :)

Original comment by stolsvik on 1 Apr 2009 at 12:54

[GoogleCodeExporter]

I think a ConcurrentMultimap sounds great.  My use case is analogous to 
collecting 
property change listeners.  The multimap is keyed by a property and can have 
multiple 
listeners associated with it.  Mutations are rare compared to traversing the 
different views to notify listeners of something.  
Multimaps.synchronizedMultimap 
requires me to manually synchronized on the entire collection each time I want 
to 
iterate a view of it.

I guess read-only/unmodifiable views would also solve my problem.

For a single listener list, java.util.concurrent.CopyOnWriteArrayList works 
well.

Original comment by will.h...@gmail.com on 15 Apr 2009 at 6:51

[GoogleCodeExporter]

The use-cases I am seeing Multimap in are the property change listener pattern 
as
well as tracking references to "user" sessions (i.e. entityid -> set of session
handles) for session management.

ConcurrentMultimap.remove(K,V) particularly I would like to see implemented 
correctly
to handle the pruning data race.

Original comment by karlthep...@gmail.com on 12 Jun 2009 at 1:15

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:57

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:02

• Added labels: Milestone-Post1.0

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved