Hi Galder !
Thanks for your comments and ideas ! I'm going to move the content you
posted in the list to the design PR here :
infinispan-designs/pull/3
++
Katia
On Thu, Apr 13, 2017 at 11:31 PM, Galder Zamarreño <galder(a)redhat.com>
wrote:
--
Galder Zamarreño
Infinispan, Red Hat
> On 5 Apr 2017, at 10:05, Sebastian Laskawiec <slaskawi(a)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.
Hmmmm, that would only really work for a synchronous API version. For
async you'd something like Traversable that we did for the functional map
experiment.
> 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(a)gmail.com>
wrote:
> On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <karesti(a)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.
>
> 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.
>
>
>
>
> 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(a)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
> --
> SEBASTIAN ŁASKAWIEC
> INFINISPAN DEVELOPER
> Red Hat EMEA
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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