Re: [infinispan-dev] Native Infinispan Multimap support

Hi all I've moved the discussion to infinispan-designs https://github.com/infinispan/infinispan-designs/pull/3 I think I put everything we said on this thread. Let me know if I forgot something important on the PR. Let's continue the design on Github, should be nicer to follow ! :)

Cheers Katia On Thu, Apr 6, 2017 at 2:29 PM, Katia Aresti <karesti(a)redhat.com&gt; wrote: > > What if we move the discussion to > https://github.com/infinispan/infinispan-designs ? > > > Katia > > On Thu, Apr 6, 2017 at 11:04 AM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: >> >> On 04/06/2017 12:15 AM, Katia Aresti wrote: >> > >> > >> > On Wed, Apr 5, 2017 at 9:56 AM, Radim Vansa <rvansa(a)redhat.com >> > <mailto:rvansa@redhat.com>> wrote: >> > >> > On 04/04/2017 06:40 PM, William Burns wrote: >> > > >> > > >> > > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)redhat.com >> > <mailto:karesti@redhat.com> >> > > <mailto:karesti@redhat.com <mailto:karesti@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> { >> > > >> > >> > I don't see anything async in this interface. If that's async, >> > provide >> > CompletableFuture return values. >> > I am also considering if we want any fire & forget variants for >> > these >> > operations, but since we have to do retries to achieve consistency >> > (and >> > therefore we need some messages from owners to originator), I >> > wouldn't >> > include them. >> > >> > >> > Today's vert-x API calls the vertx.executeBlocking(future => cache...) >> > >> > I considered the option of CompletableFuture, but for simplicity I >> > suggested the basic method. >> > Today's CacheAPI makes a difference between "put" and "putAsync". >> > Would you call the interface CacheMultimapAsync or CacheMultimap with >> > addAsyc method ? >> >> "In a perfect world, there will be no war or hunger, all APIs will be >> written asynchronously and bunny rabbits will skip hand-in-hand with >> baby lambs across sunny green meadows." (quoting Vert.x docs) >> >> While minimalistic API is a good way to start, it shouldn't contain >> anything we'd want to get rid of in close future. And especially since >> the main drive for multimaps is Vert.x which consumes asynchronous APIs >> (and has support for legacy synchronous APIs, the executeBlocking >> method), we should have the design adapted to that from the beginning. >> >> CompletableFuture is not a rocket science, and you can use the already >> asynchronous Infinispan internals. >> >> I don't think we should have two interfaces, I believe that single >> interface with async methods only is absolutely sufficient. Though I >> wouldn't add the *Async suffix at all there. If someone wants to execute >> the methods synchronously he can call .get() or .join() - just 6/7 >> characters more. >> >> > >> > > 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. >> > >> > I would rather call this "add", as vert-x does. CompletableFuture >> > as >> > return type here will allow to easily register the handler >> > >> > >> > -1 I prefer keeping "put" name because it is still a Map and makes >> > more sense to me considering the actual Cache API too. The return type >> > V was a transcription mistake, it should be void for me, as Will >> > pointed out. >> >> To me "put" is linked with overwriting the previous value, while you add >> to the underlying collection or create a new single-element one. But >> whatever, I care more about the return values :) >> >> R. >> >> > >> > >> > > 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. >> > >> > What about "reset(key)"? >> > >> > >> > > } >> > > >> > > 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); >> > > >> > > >> > > 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`. >> > >> > +1 Since the names of multimaps and maps will clash, we shouldn't >> > hide >> > that the underlying implementation is a Cache, so I'd suggest >> > something like >> > >> > static <K, V> CacheMultimap<K, V> CacheMultimapFactory.get(Cache<K, >> > Object> c) { ... } >> > >> > > >> > > >> > > 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 >> > <https://github.com/vert-x3/vertx-infinispan> >> > > >> > > [2] >> > > >> > >> > https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/... >> > >> > <https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/... >> > > >> > > [3] >> > https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c >> > <https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c> >> > > _______________________________________________ >> > > infinispan-dev mailing list >> > > infinispan-dev(a)lists.jboss.org >> > <mailto:infinispan-dev@lists.jboss.org> >> > <mailto:infinispan-dev@lists.jboss.org >> > <mailto:infinispan-dev@lists.jboss.org>> >> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >> > > >> > > >> > > >> > > _______________________________________________ >> > > infinispan-dev mailing list >> > > infinispan-dev(a)lists.jboss.org >> > <mailto:infinispan-dev@lists.jboss.org> >> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >> > >> > >> > -- >> > Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>> >> > JBoss Performance Team >> > >> > _______________________________________________ >> > infinispan-dev mailing list >> > infinispan-dev(a)lists.jboss.org >> > <mailto:infinispan-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > <https://lists.jboss.org/mailman/listinfo/infinispan-dev> >> > >> > >> > >> > >> > _______________________________________________ >> > infinispan-dev mailing list >> > infinispan-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Radim Vansa <rvansa(a)redhat.com&gt; >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev