[infinispan-dev] Native Infinispan Multimap support

[Katia Aresti]

Hi Galder !

Thanks for your comments and ideas  ! I'm going to move the content you
posted in the list to the design PR here : https://github.com/infinispan/
infinispan-designs/pull/3

++

Katia

On Thu, Apr 13, 2017 at 11:31 PM, Galder Zamarreño <galder at redhat.com>
wrote:

>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 5 Apr 2017, at 10:05, Sebastian Laskawiec <slaskawi at 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.
>
> Hmmmm, that would only really work for a synchronous API version. For
> async you'd something like Traversable that we did for the functional map
> experiment.
>
> > 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 <mudokonman at gmail.com>
> wrote:
> > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti at 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.
> >
> >  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.
> >
> >
> >
> >
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > --
> > SEBASTIAN ŁASKAWIEC
> > INFINISPAN DEVELOPER
> > Red Hat EMEA
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170414/d121b3bb/attachment-0001.html