ConcurrentLinkedMultimap?

[GoogleCodeExporter]

Have you considered creating a version of this data structure which allows the 
association of multiple entries per key, with separate expiry (FIFO, LRU) per 
entry? 

I have a very strong use case for such a structure, but I don't see anything 
out 
there that would satisfy it (map to set/list is not the same, as then the whole 
entry shares the same expiry.)

Original issue reported on code.google.com by ryan.daum on 9 Dec 2009 at 6:35

[GoogleCodeExporter]

I haven't considered it in that form, but in the style you dislike. The idea 
was to 
have a mapping to a collection, which would have a weight and affect eviction 
when 
the sum(weights) exceeds the capacity. The scaling factor, such as by number of 
elements or memory usage, could be pluggable. This would allow a safe model for 
caching collections by not letting them be unbounded values.

I've only come across usage patterns where the entire entry's collection is 
needed, 
not a partially cached form. It would be very interesting to hear about your 
example.

I have recently joined Google and yesterday had lunch with Kevin Bourrillion 
(Google 
Collections) to discuss folding in some of my work into their recent efforts. I 
plan 
on making that my 20% project, so having more use-cases for Google Collections 
/ 
MapMaker / Guava would be valuable in maturing those libraries.

Original comment by Ben.Manes@gmail.com on 9 Dec 2009 at 10:43

[GoogleCodeExporter]

My example is rather proprietary (for my $work) but I don't think it's exotic 
if you 
consider that it's really about the values having the expiry rather than the 
key. In my 
case it's that I still generally want to know about the subject ("key") but let 
old 
information about that subject expire out of the cache. It's really just a 
one-to-many 
relationship, with the many having their own expiration.

Original comment by ryan.daum on 13 Dec 2009 at 8:00

[GoogleCodeExporter]

If I am not mistaken, this is actually asking for two distinct things:

1) A multimap in which there can be multiple values associated with each key. 
(This
implies a whole new set of method signatures in an interface, and many other
implementations.  These may exist elsewhere.)  I will agree that this is one 
case a
multimap can't be cleanly built from a map.

2) The ability to put a specific EvictionPolicy on each entry in the map, 
instead of
on the map as a whole.  This could allow for a new EvictionPolicy of "never 
evict
me", allowing selected entries to be made permanent.

Both are interesting ideas...

Original comment by divad27...@gmail.com on 30 Mar 2010 at 10:34

[GoogleCodeExporter]

(1) covered in Google Collections / Guava, which has a family of 
implementations.

(2) could be implemented as a composite structure, I think. It would require 
coordination between the a Multimap<K, V> and ConcurrentLinkedHashMap<V, K>, 
and an 
eviction listener that drops the value from the multimap. The CLHM's value 
would use 
the identity equals/hashCode to ensure uniqueness. Each eviction strategy would 
be 
associated with a different eviction map (e.g. lru to CLHM, none to CHM).

I don't know of a use-case where I'd need to implement it, but I think that's 
the 
easiest approach for how to do it. At least it would help flush out enough 
details 
that while it may not be optimal, an improved rewrite would be feasible. I 
would 
propose this to Guava if there's still interest.

Original comment by Ben.Manes@gmail.com on 30 Mar 2010 at 11:18

[GoogleCodeExporter]

Please submit to Guava. This won't be supported through this library.

Original comment by Ben.Manes@gmail.com on 3 Apr 2010 at 4:27

• Changed state: Invalid