[infinispan-dev] Native Infinispan Multimap support

[Radim Vansa]

On 04/04/2017 06:40 PM, William Burns wrote:
>
>
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti at redhat.com 
> <mailto: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> {
>

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.

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

>         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
>
>     [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 <mailto: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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team