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