On 04/05/2017 04:34 PM, William Burns wrote: > > > On Wed, Apr 5, 2017 at 4:30 AM Sebastian Laskawiec > <slask...@redhat.com <mailto:slask...@redhat.com>> wrote: > > I love the idea of starting with a simple interface, so +1000 from > me. > > I'm also assuming that our new MultiMap will be accessible in both > Embedded and Client/Server mode, am I correct? I also think > CacheMultimap should extend Iterable. I suspect some of our users > might want to use for-each loop with it. Finally, we also need to > think about some integration bits (maybe not for the initial > implementation but it might be beneficial to create JIRAs for > them). With CDI and Spring support we can make them super easy to > use (by injecting newly created instances to the users code: > @Inject CacheMultimap myMap<String, String>). > > I also put some more comments below. Nice proposal Katia! > > On Tue, Apr 4, 2017 at 7:09 PM William Burns > <mudokon...@gmail.com> wrote: > > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti > <kare...@redhat.com> wrote: > > Hi all, > > As you probably know, Will and I are working on the vert-x > infinispan integration [1], where the primary goal is to > make infinispan the default cluster management of vert-x. > (yeah!) > Vert-x needs support for an Async Multimap. Today's > implementation is a wrapper on a normal Cache where only > Cache Key's are used to implement the multi map [2]. > This is not very efficient, so after trying some other > alternative implementations [3] that don't fully work > (injection not working), Will and I have come to the > conclusion that it might be a good idea to start having > our own native CacheMultimap. This first multimap won't > support duplicate values on key's. > > As a quick start, the smallest multimap we need should > implement the following interface : > > I agree that having a very slim API to start should be better > since we know how much trouble we get into implementing a very > large API like ConcurrentMap :) > > public interface CacheMultimap<K,V> { > V put(K key,V value); > > This should probably return a boolean or Void. I am leaning > towards the first, but I am open either way. > > > Could you please tell me more why are you suggesting boolean or > void? Returning previous value would make it more similar to a Map. > > > The value of the MultiMap is a Collection<V> which in this version > doesn't allow duplicates. By returning boolean we can say if the value > was added (true) or it was already present (false).
If it does not allow duplicates, why get() does not return a Set<V>? Btw., there are other ~useful return types possible, e.g. `int` returning size of the collection pre/post modification (not advocating that, though - I would personally rather see the boolean, if not CompletableFuture<Boolean>). I wouldn't return the whole previous value (full collection). > Collection<V> get(K key); > > boolean remove(K key,V value); > > We probably want a `boolean remove(K key)` method as well that > removes all values mapped to the given key. > > > +1 > > } > > CacheMultimapImpl will be a wrapper on a normal Cache, > similar to [3]. > > We could add a new method in EmbeddedCacheManager.java > > <K, V> CacheMultimap<K, V> getCacheMultimap(String > cacheName, boolean createIfAbsent); > > > How about the other way around? Something like: > static <K, V> CacheMultimap<K, V> > CacheMultimap.create(BasicCache<K,V> cache); > > This way we would avoid dependency from DefaultCacheManager > to CacheMultimap. If we wanted to support both Embedded/Client > Server mode we would probably need to use BasicCache as a > parameter. The last argument for this solution is that creating > producers in CDI/Spring would be trivial (we would just need to > provide a generic producer method and with some luck that would be > it). > > > I was thinking maybe this would exist in a separate module > (outside of core)? or class that wraps (similar to > DistributedExecutor) instead. My worry is about transactions, > since the entry point to that is through Cache interface. The > other option is we could add a `getCache` method on the > `CacheMultiMap`. > > > If we want to support both Embedded/Client Server mode, it should > go to commons. Otherwise I would vote for core. > > > Commons should work. Only problem is the functional commands don't > really work efficiently over Hot Rod (does get/replace in a loop). We > would need to add some more handling in the protocol to allow for only > partial replication of values and only 1 remote call. I guess that only the CacheMultimap interface (+ maybe some helper classes) should land in commons, the actual implementation (in hotrod-client module or its extension module) wouldn't use compute() over Hot Rod. R. > > > Implementation will create a cache as always and return a > new CacheMultimapImpl(cache). > > What do you think ? Please fell free to suggest any other > alternative or idea. > > Cheers > > Katia > > [1] https://github.com/vert-x3/vertx-infinispan > > [2] > > https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/vertx/ext/cluster/infinispan/impl/InfinispanAsyncMultiMap.java > > [3] > https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > > SEBASTIANŁASKAWIEC > > INFINISPAN DEVELOPER > > Red HatEMEA > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
