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>> 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/...
[3]
https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team