ISPN-7780 multimap embedded #5193

karesti · 2017-06-12T10:46:28Z

https://issues.jboss.org/browse/ISPN-7780

Design doc PR :

rvansa

I don't see any documentation how the multimap cache will interact with expiration and eviction settings. A section in documentation would be welcome.

rvansa · 2017-06-12T10:57:18Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+
+   /**
+    * Removes a value on a key. In the case where duplicates are supported, all the values will be removed.
+    * After remove call, the remaining value on the key might be an Empty Collection. In this case, the key is removed


just say that the whole entry will be removed - no upper case needed for 'Empty Collection', btw

rvansa · 2017-06-12T10:58:32Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+   CompletableFuture<Boolean> remove(K key, V value);
+
+   /**
+    * Removes all the values in every key that matches the given {@link Predicate}.


s/matches/match/

@rvansa Actually matches is correct here :)

@danberindei it's not a the key that matches the predicate, since the predicate does not accept the key, therefore values ... match

Oops, I should have read the function declaration before replying :)

Then I think s/matches/match/ is not enough, it should be something like "Remove the values that match the given Predicate from all the keys".

rvansa · 2017-06-12T11:00:53Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+   /**
+    * Removes all the values in every key that matches the given {@link Predicate}.
+    *
+    * For now, this method returns a completed future


...the implementation of this method executes synchronously and returns a completed future. In future this might be changed.

Does this behavior apply behavior apply to all methods?

@tsegismont no, just the methods that are marked with the doc. But this might change soon. I have to speak to the team to see the best way to do it.

rvansa · 2017-06-12T11:11:31Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    *
+    * @return long, the size
+    */
+   CompletableFuture<Integer> size();


use rather CF<Long>, and update @return javadoc

yes, I was thinking about that earlier too

rvansa · 2017-06-12T11:14:58Z

multimap/src/main/java/org/infinispan/multimap/impl/EmbeddedMultimapCache.java

+   @Override
+   public CompletableFuture<Collection<V>> get(K key) {
+      SerializableBiFunction<? super Collection<V>, Throwable, Collection<V>> emptyCollectionWhenNull = (vs, throwable) -> vs == null ? new HashSet<>() : vs;
+      return cache.getAsync(key).handle(emptyCollectionWhenNull);


emptyCollectionWhenNull does not need to be serializable... Use thenApply instead of handle and return rather Collections.emptySet()

We also need to make sure this is a copy of the collection, just in case. Otherwise if we are in a clustered cache data would get in an inconsistent state if user updates this collection on nodes that own the data.

@wburns good point. Changing implementation

@wburns @karesti I don't agree - the collection stored in cache should be immutable, so we should not create a copy but rather wrap it in Collections.unmodifiableCollection.

rvansa · 2017-06-12T12:17:33Z

multimap/src/test/java/org/infinispan/multimap/impl/EmbeddedMultimapCacheTest.java

+
+   public void testPut() {
+      await(
+            multimapCache.put("names", "julien").thenCompose(r1 ->


You're chaining it wrong, should be:

multimapCache.put("names", "julien") .thenCompose(r -> multimapCache.put("names", "oihana")) .thenCompose(r -> multimapCache.put("names", "julien")) .thenCompose(r -> multimapCache.get("names"))

That applies to the rest of chains as well.

rvansa · 2017-06-12T12:19:32Z

multimap/src/test/java/org/infinispan/multimap/impl/EmbeddedMultimapCacheTest.java

+   }
+
+   public void testPut() {
+      await(


unless you need the timeout, use CF.join() instead of await

@karesti please do use a timeout in tests, even if you think you don't need it :)

I'm using await

rvansa · 2017-06-12T12:24:21Z

multimap/src/test/java/org/infinispan/multimap/impl/TxEmbeddedMultimapCacheTest.java

+ * @since 9.1
+ */
+@Test(groups = "functional", testName = "multimap.TxEmbeddedMultimapCacheTest")
+public class TxEmbeddedMultimapCacheTest extends EmbeddedMultimapCacheTest {


You should probably test with both pessimistic and optimistic transactions, and pessimistic with both RC and RR isolation levels. Also multi-node tests can reveal more issues than single-node ones, I think (testing both owner and non-owner variant).

Also if you can using the factory or @factory annotation would be preferred over using different classes. Unless there are a lot of differences between how the tests run.

rvansa · 2017-06-12T12:26:40Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+ * MultimapCache provides the common building block for the two different types of multimap caches that Infinispan
+ * provides: embedded and remote.
+ * <p>
+ * Please see the <a href="http://www.jboss.org/infinispan/docs">Infinispan documentation</a> and/or the <a


These links are outdated and don't say anything about multimap cache.

rvansa · 2017-06-12T12:26:50Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+ * <p/>
+ *
+ * @author Katia Aresti, karesti@redhat.com
+ * @see <a href="http://www.jboss.org/infinispan/docs">Infinispan documentation</a>


outdated link

wburns

I haven't had a chance to look over tests, but put some comments on docs and impl.

wburns · 2017-06-12T12:48:59Z

multimap/src/main/java/org/infinispan/multimap/EmbeddedMultimapCacheManagerFactory.java

+    */
+
+   public static <K, V> MultimapCache<K, V> get(String name, EmbeddedCacheManager cacheManager, Configuration configuration) {
+      cacheManager.defineConfiguration("test", configuration);


Think you meant to do something else with the configuration here.

wburns · 2017-06-12T12:52:09Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    *
+    * Returns duplicates are supported or not in this multimap cache
+    *
+    * @return true or false


that is implied by the defined return type. "@return true if this multicache supports duplicate values for a given key" or something like that.

wburns · 2017-06-12T12:54:44Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+   /**
+    * Removes a value on a key. In the case where duplicates are supported, all the values will be removed.
+    * After remove call, the remaining value on the key might be an Empty Collection. In this case, the key is removed
+    * fro this multimap cache.


wburns · 2017-06-12T12:56:30Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    *
+    * @param key, to be removed
+    * @param value, to be removed
+    * @return boolean, remove result


"@return true if the value has been removed, including if the entire key was removed due to the value being the last one" something like this.

wburns · 2017-06-12T12:57:29Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+   CompletableFuture<Boolean> remove(K key);
+
+   /**
+    * Removes a value on a key. In the case where duplicates are supported, all the values will be removed.


"all of the duplicate values will be removed"

wburns · 2017-06-12T13:44:17Z

multimap/src/main/java/org/infinispan/multimap/impl/EmbeddedMultimapCache.java

+   @Override
+   public CompletableFuture<Collection<V>> get(K key) {
+      SerializableBiFunction<? super Collection<V>, Throwable, Collection<V>> emptyCollectionWhenNull = (vs, throwable) -> vs == null ? new HashSet<>() : vs;
+      return cache.getAsync(key).handle(emptyCollectionWhenNull);


We also need to make sure this is a copy of the collection, just in case. Otherwise if we are in a clustered cache data would get in an inconsistent state if user updates this collection on nodes that own the data.

wburns · 2017-06-12T13:45:45Z

multimap/src/main/java/org/infinispan/multimap/impl/EmbeddedMultimapCache.java

+               Collection<V> values = (Collection<V>) o1;
+               Collection<V> newValues = new HashSet<>();
+
+               for (V v : values) {


~~Seems we could just use the iterator on the collection and just call remove if it doesn't pass the predicate.~~

nope, as above

wburns · 2017-06-12T13:46:13Z

multimap/src/main/java/org/infinispan/multimap/impl/MultimapModuleLifecycle.java

+import org.kohsuke.MetaInfServices;
+
+/**
+ * Used to add exterlizers


wburns · 2017-06-12T13:46:43Z

multimap/src/main/java/org/infinispan/multimap/impl/function/BaseFunction.java

+ * @author Katia Aresti, karesti@redhat.com
+ * @since 9.1
+ */
+abstract class BaseFunction<K, V, R> implements SerializableFunction<EntryView.ReadWriteEntryView<K, Collection<V>>, R> {}


This can just be an interface

wburns · 2017-06-12T13:48:12Z

multimap/src/main/java/org/infinispan/multimap/impl/function/PutFunction.java

+
+      try {
+         // Raises NoSuchElementException if the value does not exist
+         Collection<V> values = entryView.get();


~~Hrmm if the entry exists can't we just add the new value to it and set it back in the view? Otherwise the update will get progressively slower.~~

Collection<V> newValues = entryView.find().map(HashSet::new).orElseGet(HashSet::new);
newValues.add(value)
entryView.set(newValues)

wburns · 2017-06-12T14:01:40Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    *
+    * @param p, the predicate to be tested on every value in the multimap cache
+    */
+   CompletableFuture<Void> remove(Predicate<? super V> p);


Oh also we probably want a SerializablePredicate override for this.

@wburns Yep. I wanted to add it but this class is in commons and SerializablePredicate is in core ... This joins the pb Radim asked about on a mail last friday.

Same thing as I posted on there, we should just add an additional interface in commons for this. We can worry about refactoring core in a major version. At least my 2cents.

Actually, predicate-based methods won't fly in client-server - Hot Rod is language neutral and therefore can't carry lambdas. That's why the SerializableFunction et all are in core and not in commons.
For client-server you'll need to register the filter on server-side, and refer to it by name. Alternatively you could do the filtering using Ickle query.

wburns · 2017-06-12T14:15:09Z

multimap/src/main/java/org/infinispan/multimap/impl/function/RemoveFunction.java

+         // Raises NoSuchElementException if the key/value does not exist
+         Collection<V> values = entryView.get();
+
+         if(value == null) {


wburns · 2017-06-13T13:11:53Z

I am more than aware of that, hence my email before. But this doesn't stop the Java client from performing a lambda on results from the server. If we want to have separate, but similar, API for embedded and remote I am fine with that. Then to me this API shouldn't exist in commons. We could have a super set, such as BaseFeature that you mentioned in the email.

…

On Tue, Jun 13, 2017, 4:12 AM Radim Vansa ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java <#5193 (comment)> : > + * Returns true when the value has been removed from the key. + * + * @param key, to be removed + * @param value, to be removed + * @return boolean, remove result + */ + CompletableFuture<Boolean> remove(K key, V value); + + /** + * Removes all the values in every key that matches the given ***@***.*** Predicate}. + * + * For now, this method returns a completed future + * + * @param p, the predicate to be tested on every value in the multimap cache + */ + CompletableFuture<Void> remove(Predicate<? super V> p); Actually, predicate-based methods won't fly in client-server - Hot Rod is language neutral and therefore can't carry lambdas. That's why the SerializableFunction et all are in core and not in commons. For client-server you'll need to register the filter on server-side, and refer to it by name. Alternatively you could do the filtering using Ickle query. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5193 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnj7985fb4cpy8eVBCtrIwENCLQVv0Zks5sDjr8gaJpZM4N28Xq> .

tsegismont · 2017-06-13T13:34:00Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    * @return the collection found in the key when it's present,
+    *         empty Collection when the key is not present
+    */
+   CompletableFuture<Collection<V>> get(K key);


Will this be a copy or a view of the values in the cluster?

@tsegismont This will be a copy. Collections.unmodifiableCollection(v)
Changes are not allowed, and if the user needs to modify the collection directly, it should create a new one from the answer.
What do you think ?

tsegismont · 2017-06-13T13:36:25Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+   /**
+    * Removes all the values in every key that matches the given {@link Predicate}.
+    *
+    * For now, this method returns a completed future


Does this behavior apply behavior apply to all methods?

wburns · 2017-06-14T17:10:58Z

Talking to @karesti about the async executor, I guess we can't use this in a tx context as there is no way to get the tx context into the spawned thread. And I don't know if I like having to have a method to inject an InvocationContext or Transaction although that would be possible as part of AdvancedCache API / DecoratedCache. Guess I am fine with it blocking for now :/

rvansa · 2017-06-15T10:08:57Z

@wburns Why can't you suspend and resume the transaction? You can even call

Transaction tx = transactionManager.getTransaction();
executor.execute(() -> {
    transactionManager.resume(tx);
    // do something else
});

wburns · 2017-06-15T11:56:13Z

@wburns Why can't you suspend and resume the transaction?

@rvansa That was my initial thought as well, but we can't do this as the calling thread has to keep the transaction on it.

You can even call <code>

@rvansa Afaik you can't share the transaction between multiple threads. The old async operations never resumed the transaction in the async thread when an explicit tx was present, they just updated the InvocationContext. Are you sure that we can have more than 1 thread associated with the same transaction? You probably know more about the finer details of the xa spec than I do (the javadoc don't seem to detail this case). Would all the various TransactionManagers support this?

rvansa · 2017-06-15T12:48:31Z

@wburns As you've said, JTA is not clear in this part so I've asked Narayana guys and they've confirmed that there's no issue with it in JBoss TM. The first thread that calls tm.commit()/tm.rollback() ends the transaction, and TM prevents multiple invocations. However, if you have an ongoing transaction and other thread commits it while you're doing sth. with that, problems may arise - it's up to the app to not call commit until all participants are ready.
It seems that it was not same with Atomikos but things may have changes since 2009. Other report that Bitronix does not support that.

wburns · 2017-06-15T12:55:23Z

@rvansa So I am on the fence either way, whichever people prefer. The one thing I do like is that according to that stack overflow post that supposedly JTA spec does allow multiple threads to be associated with the same transaction. I double checked and that line is there at http://download.oracle.com/otndocs/jcp/jta-1.1-spec-oth-JSpec/

karesti · 2017-06-15T21:03:18Z

@wburns @rvansa concerning the explicit tx, I'm blocking whenever a explicit tx is ongoing for the methods that fail if I don't don't block. I've documented it on the interface.
I'm going to continue with other stuff on this multimap, and I will come to tx later if you don't mind.

tsegismont · 2017-06-16T07:25:28Z

@karesti maybe a stupid question, but they say it's always worth asking :)

Looking at EmbeddedMultimapCacheManagerFactory, I see that a multicache is created from a backing "standard" cache. Does that mean that a multicache can be either distributed or replicated?

And since distribution happens on keys, primary and backups will have the whole collection for a key. Is that correct?

I'm just asking to understand, not saying if it's right or wrong.

rvansa · 2017-06-16T07:30:46Z

@tsegismont Your understanding is correct. While the entries wouldn't be load-balanced perfectly, this is the easiest way to implement multimaps in Infinispan.

tsegismont · 2017-06-16T07:49:20Z

Thanks @rvansa !

tsegismont · 2017-06-16T16:51:19Z

commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    * @return the collection found in the key when it's present,
+    *         empty Collection when the key is not present
+    */
+   CompletableFuture<Collection<V>> get(K key);


This is fine for the Vert.x cluster manager. We never modify the collection directly. 2017-06-16 15:00 GMT+02:00 Katia Aresti <notifications@github.com>:
…

In commons/src/main/java/org/infinispan/multimap/api/MultimapCache.java <#5193 (comment)> : > + * If the multimap cache does not support duplicates and the value exists on the key, nothing will be done. > + * > + * @param key, the key to be put > + * @param value, the value to added > + */ > + CompletableFuture<Void> put(K key, V value); > + > + /*** > + * Returns a view collection of the values associated with key in this multimap cache, if any. > + * Any changes to the retrieved collection won't change the values in this multimap cache. > + * > + * @param key, to be retrieved > + * @return the collection found in the key when it's present, > + * empty Collection when the key is not present > + */ > + CompletableFuture<Collection<V>> get(K key); @tsegismont <https://github.com/tsegismont> This will be a copy. Collections.unmodifiableCollection(v) Changes are not allowed, and if the user needs to modify the collection directly, it should create a new one from the answer. What do you think ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/infinispan/infinispan/pull/5193/files/dba0facf1ff077f1bc0a197032e709077ba91706#r122435347>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABblthrx5iz3Pp1s4FQnVZwd51JiyKH-ks5sEnxogaJpZM4N28Xq> .

galderz · 2017-07-26T08:24:31Z

What are we waiting for to integrate this in? It was open early June :\

IMO, this should have included in 9.1.0.Final with follow up JIRAs for missing orthogonal features (transaction support, encoding support...etc) :(

galderz · 2017-07-26T08:25:31Z

To note: commits for ISPN-7993 should be out of this PR.

karesti · 2017-07-26T08:59:27Z

@galderz I removed the rebase from ISPN-7993 and removed the tests OFF_HEAP storage type is working

rvansa

Sorry, I've lost this from the radar. Looks mostly OK, just the keys in functions are redundant. And I would consider having a null-valued Contains and Remove static instances.

rvansa · 2017-07-26T10:31:19Z

multimap/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+ * <p>
+ * <h2>Transactions</h2> MultimapCache supports implicit transactions without blocking. The following methods block when
+ * they are called in a explicit transaction context. This limitation could be improved in the followin versions if
+ * technically possible. <ul> <li>{@link MultimapCache#size()}</li> <li>{@link MultimapCache#containsEntry(Object,


Please one method per line. And btw., in javadoc it is preferred to omit the closing </li> as it improves readability in source.

didn't know for the closing li. Correcting

rvansa · 2017-07-26T10:33:59Z

multimap/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    *
+    * @since 9.2
+    */
+   CompletableFuture<Optional<CacheEntry<K, Collection<V>>>> getEntry(K key);


Why is there the Optional? Javadoc does not match

I copied the java doc on cache and changed after to optional, didn't realize, thanks for pointing

rvansa · 2017-07-26T10:34:46Z

multimap/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+ * Future implementations might evolve to support duplicated values.
+ * <p>
+ * <h2>Transactions</h2> MultimapCache supports implicit transactions without blocking. The following methods block when
+ * they are called in a explicit transaction context. This limitation could be improved in the followin versions if


typo: followin

rvansa · 2017-07-26T10:35:47Z

multimap/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+    * nothing will be done.</li>
+    * </ul>
+    *
+    * @param key,   the key to be put


why do you have the comma after param name?

why not, comma are pretty 💃
TBH, I don't know why or when I took the idea from, and I repeated the , in my javadoc. Removing them

rvansa · 2017-07-26T10:36:59Z

multimap/src/main/java/org/infinispan/multimap/api/MultimapCacheManager.java

+   /**
+    * Defines a named multimap cache's configuration by using the provided configuration
+    * If this cache was already configured either declaritively or programmatically this method will throw a
+    * {@link org.infinispan.commons.CacheConfigurationException}.


Please define the relationship with regular cache names

I created https://issues.jboss.org/browse/ISPN-8105 to handle that

I don't think that such checks are necessary, I just want to document that multimap "x" is just a different view to cache "x".

rvansa · 2017-07-26T11:11:08Z

multimap/src/test/java/org/infinispan/multimap/impl/DistributedMultimapCacheTest.java

+@Test(groups = "functional", testName = "distribution.DistributedMultimapCacheTest")
+public class DistributedMultimapCacheTest extends BaseDistFunctionalTest<String, Collection<User>> {
+
+   protected Map<Address, MultimapCache<String, User>> multimapCacheCluster = new HashMap<>();


I would rather store them in a list so that you can call multimap(0) in the same way as you do cache(0) in core testsuite.

rvansa · 2017-07-26T11:22:41Z

multimap/src/test/java/org/infinispan/multimap/impl/DistributedMultimapCacheTest.java

+   }
+
+   protected MultimapCache getMultimapCacheSecondOwner(String key) {
+      Cache<String, Collection<User>> cache = getSecondNonOwner(key);


second non owner?

not used method anymore, I removed

rvansa · 2017-07-26T11:28:21Z

multimap/src/test/java/org/infinispan/multimap/impl/EmbeddedMultimapCacheTest.java

+import org.testng.annotations.Test;
+
+/**
+ * Single Multimap Cache Test


And do we need both single-node and multinode test? Can be the code shared in any way?

well, configuration is different, I like having the simple test too, I'm going to rework it to avoid unnecessary duplication, I agree on that

rvansa · 2017-07-26T11:30:17Z

multimap/src/test/java/org/infinispan/multimap/impl/StoreTypeMultimapCacheTest.java

+import org.testng.annotations.Test;
+import org.junit.Ignore;
+
+//TODO: Integrate https://issues.jboss.org/browse/ISPN-7993 to make it pass


let's move this test out of the PR if 7993 does not get in before that

rvansa · 2017-07-26T11:35:31Z

...ence/jpa/src/main/java/org/infinispan/persistence/jpa/impl/EntityManagerFactoryRegistry.java

@@ -10,6 +10,8 @@
 import javax.persistence.spi.PersistenceProvider;

 import org.infinispan.commons.util.Util;
+import org.infinispan.factories.scopes.Scope;


are these imports necessary?

no, this has been added by error and not removed on amend

tristantarrant · 2017-08-02T13:51:12Z

Temporarily closing because of CI overload

karesti · 2017-08-02T13:52:17Z

@tristantarrant you scared me there

galderz · 2017-09-27T14:17:24Z

Needs rebasing :|

karesti · 2017-09-28T12:21:08Z

@galderz properly rebased

tristantarrant · 2017-09-28T15:41:23Z

documentation/src/main/asciidoc/user_guide/multimapcache.adoc

@@ -0,0 +1,155 @@
+== Multimap Cache
+
+Infinispan Multimap Cache is a new distributed and clustered collection type introduced in Infinispan 9.


tristantarrant · 2017-09-28T15:56:50Z

documentation/src/main/asciidoc/user_guide/multimapcache.adoc

+
+=== Creating a Multimap Cache
+
+In version 9.2, the MultimapCache is configured as a regular cache. This can be done either by code or XML configuration.


Better not use version numbers, just say "Currently".

tristantarrant · 2017-09-28T15:57:01Z

documentation/src/main/asciidoc/user_guide/multimapcache.adoc

+
+=== Limitations
+
+In almost every case the Multimap Cache will behave as a regular Cache, but some limitations exist in the first 9.2 version.


again, avoid version numbers.

tristantarrant · 2017-09-28T15:58:37Z

documentation/src/main/asciidoc/user_guide/user_guide.asciidoc

@@ -36,3 +36,4 @@ include::rolling_upgrades.adoc[]
 include::extending.adoc[]
 include::architecture.adoc[]
 include::counters.adoc[]
+include::multimapcache.adoc[]


I think we should move both counters and multimapcache docs further up, after query, before CDI.

tristantarrant · 2017-09-28T16:01:54Z

multimap/src/main/java/org/infinispan/multimap/api/MultimapCache.java

+ *  </pre>
+ * <p>
+ * <p>
+ * <h2>Duplicates</h2> Today's implementation does not support duplicate values on keys. {@link Object#equals(Object)}


s/Today's/The current/

* The API is asynchronous * Mutimap cache is based on regular cache * There is a limitation on tx caches, some mehods will block * Added storage type test, attending ISPN-7993 * Added getEntry method for hotrod * Eenhancements in MultiMap tests

karesti · 2017-09-28T20:15:10Z

@tristantarrant I reported the changes you asked on documentation

tristantarrant · 2017-09-29T09:46:39Z

Merged to master

karesti added the Preview label Jun 12, 2017

karesti force-pushed the ISPN-7780-cache-mutimap branch from 63c79fd to 972262a Compare June 12, 2017 10:48

karesti mentioned this pull request Jun 12, 2017

Multimap design with mail discussion infinispan/infinispan-designs#3

Merged

rvansa requested changes Jun 12, 2017

View reviewed changes

wburns requested changes Jun 12, 2017

View reviewed changes

wburns reviewed Jun 12, 2017

View reviewed changes

tsegismont reviewed Jun 13, 2017

View reviewed changes

karesti force-pushed the ISPN-7780-cache-mutimap branch from 0e3bdec to c318358 Compare June 14, 2017 15:08

karesti force-pushed the ISPN-7780-cache-mutimap branch from c318358 to 9c2026e Compare June 15, 2017 10:18

tsegismont reviewed Jun 16, 2017
View reviewed changes

karesti force-pushed the ISPN-7780-cache-mutimap branch 6 times, most recently from f88d668 to 8693df7 Compare June 21, 2017 09:46

karesti changed the title ~~ISPN-7780 multimap embedded first shot - dist mode fails with eval~~ ISPN-7780 multimap embedded Jun 21, 2017

karesti added Ready for Review labels Jun 21, 2017

karesti force-pushed the ISPN-7780-cache-mutimap branch 2 times, most recently from 2a45116 to 85e13d1 Compare July 26, 2017 08:59

rvansa reviewed Jul 26, 2017

View reviewed changes

karesti force-pushed the ISPN-7780-cache-mutimap branch 2 times, most recently from 20afa03 to 315da88 Compare July 30, 2017 10:00

tristantarrant closed this Aug 2, 2017

karesti reopened this Sep 27, 2017

galderz added the Needs Rebase label Sep 27, 2017

karesti force-pushed the ISPN-7780-cache-mutimap branch from e8c6482 to 692b0eb Compare September 28, 2017 08:39

karesti removed the Needs Rebase label Sep 28, 2017

karesti force-pushed the ISPN-7780-cache-mutimap branch 2 times, most recently from a2b2ab9 to 6345514 Compare September 28, 2017 12:20

tristantarrant reviewed Sep 28, 2017

View reviewed changes

karesti force-pushed the ISPN-7780-cache-mutimap branch from 6345514 to 39ca601 Compare September 28, 2017 20:14

tristantarrant merged commit cb025da into infinispan:master Sep 29, 2017

karesti deleted the ISPN-7780-cache-mutimap branch February 6, 2019 11:28

		@@ -0,0 +1,155 @@
		== Multimap Cache

		Infinispan Multimap Cache is a new distributed and clustered collection type introduced in Infinispan 9.


		=== Creating a Multimap Cache

		In version 9.2, the MultimapCache is configured as a regular cache. This can be done either by code or XML configuration.


		=== Limitations

		In almost every case the Multimap Cache will behave as a regular Cache, but some limitations exist in the first 9.2 version.

ISPN-7780 multimap embedded #5193

ISPN-7780 multimap embedded #5193

Conversation

karesti commented Jun 12, 2017 • edited

rvansa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns Jun 12, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns Jun 12, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns commented Jun 13, 2017 via email

Choose a reason for hiding this comment

karesti Jun 16, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wburns commented Jun 14, 2017

rvansa commented Jun 15, 2017 • edited

wburns commented Jun 15, 2017

rvansa commented Jun 15, 2017

wburns commented Jun 15, 2017

karesti commented Jun 15, 2017 • edited

tsegismont commented Jun 16, 2017

rvansa commented Jun 16, 2017

tsegismont commented Jun 16, 2017

tsegismont Jun 16, 2017 via email

Choose a reason for hiding this comment

galderz commented Jul 26, 2017

galderz commented Jul 26, 2017

karesti commented Jul 26, 2017 • edited

rvansa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karesti Jul 26, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karesti commented Jun 12, 2017 •

edited

wburns Jun 12, 2017 •

edited

wburns Jun 12, 2017 •

edited

karesti Jun 16, 2017 •

edited

rvansa commented Jun 15, 2017 •

edited

karesti commented Jun 15, 2017 •

edited

karesti commented Jul 26, 2017 •

edited

karesti Jul 26, 2017 •

edited