[infinispan-dev] Native Infinispan Multimap support
Radim Vansa
rvansa at redhat.com
Thu Apr 6 04:42:33 EDT 2017
On 04/05/2017 04:34 PM, William Burns wrote:
>
>
> On Wed, Apr 5, 2017 at 4:30 AM Sebastian Laskawiec
> <slaskawi at redhat.com <mailto: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).
If it does not allow duplicates, why get() does not return a Set<V>?
Btw., there are other ~useful return types possible, e.g. `int`
returning size of the collection pre/post modification (not advocating
that, though - I would personally rather see the boolean, if not
CompletableFuture<Boolean>).
I wouldn't return the whole previous value (full collection).
> 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.
I guess that only the CacheMultimap interface (+ maybe some helper
classes) should land in commons, the actual implementation (in
hotrod-client module or its extension module) wouldn't use compute()
over Hot Rod.
R.
>
>
> 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 HatEMEA
>
> _______________________________________________
> 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
--
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team
More information about the infinispan-dev
mailing list