ignite-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [ignite] sk0x50 commented on a change in pull request #5656: IGNITE-10663 Read Repair
Date Wed, 10 Jul 2019 12:32:12 GMT
sk0x50 commented on a change in pull request #5656: IGNITE-10663 Read Repair
URL: https://github.com/apache/ignite/pull/5656#discussion_r302034854
 
 

 ##########
 File path: modules/core/src/main/java/org/apache/ignite/IgniteCache.java
 ##########
 @@ -136,6 +136,41 @@
      */
     public IgniteCache<K, V> withPartitionRecover();
 
+    /**
+     * Gets an instance of {@code IgniteCache} that will perform backup nodes check on each
get attempt.
+     * <p>
+     * Read Repair means that each backup node will be checked to have the same entry as
primary node has,
+     * and in case consistency violation found:
+     * <ul>
+     *  <li>for transactional caches:
+     *  <p>values across the topology will be replaced by latest versioned value:
+     *  <ul>
+     *      <li>automaticaly for OPTIMISTIC || READ_COMMITTED transactions</li>
+     *      <li>at commit() for PESSIMISTIC && !READ_COMMITTED transactions</li>
+     *  </ul>
+     *  <p>consistency violation event will be recorded in case it's configured as
recordable</li>
+     *  <li>for atomic caches: consistency violation exception will be thrown.</li>
+     * </ul>
+     * <p>
+     * One more important thing is that this proxy usage does not guarantee "all copies check"
in case value
+     * already cached inside the transaction. In case you use !READ_COMMITTED isolation mode
and already have
+     * cached value, for example already read the value or performed a write, you'll gain
the cached value.
+     * <p>
+     * Local caches and caches without backups, obviously, can not be checked using this
feature.
+     * <p>
+     * Full list of repairable methods:
+     * <ul>
+     * <li>{@link IgniteCache#containsKey} && {@link IgniteCache#containsKeyAsync}</li>
+     * <li>{@link IgniteCache#containsKeys} && {@link IgniteCache#containsKeysAsync}</li>
+     * <li>{@link IgniteCache#getEntry} && {@link IgniteCache#getEntryAsync}</li>
+     * <li>{@link IgniteCache#getEntries} && {@link IgniteCache#getEntriesAsync}</li>
+     * <li>{@link IgniteCache#get} && {@link IgniteCache#getAsync}</li>
+     * <li>{@link IgniteCache#getAll} && {@link IgniteCache#getAllAsync}</li>
+     * </ul>
+     * @return Cache with explicit consistency check on each read and repair if necessary.
 
 Review comment:
   Perhaps, we need to clearly clarify the limitations. I mean use cases when the ReadReapir
feature does not work (unrecoverable cases): data streamer constraints and etc. What do you
think?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message