[infinispan-dev] Native Infinispan Multimap support

William Burns mudokonman at gmail.com
Wed Apr 5 10:34:50 EDT 2017


On Wed, Apr 5, 2017 at 4:30 AM 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. 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.
>

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).


>
>
>    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.


>
>
>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170405/30f8f1cc/attachment.html 


More information about the infinispan-dev mailing list