Read Repair
Warning
|
Experimental API. |
"Read Repair" refers to a technique of repairing inconsistencies between primary and backup copies of data during normal read operations. When a specific key (or keys) is read by a user operation, Ignite checks the values for the given key in all backup copies.
The Read Repair mode is designed to maintain consistency. However, read operations become ~2 times more costly because backup copies are checked. It is generally not advisable to use this mode all the time, but rather on a once-in-a-while basis.
To enable Read Repair mode, obtain an instance of the cache that enables Read Repair reads as follows:
IgniteCache<Object, Object> cache = ignite.cache("my_cache").withReadRepair();
Object value = cache.get(10);
A consistency check is incompatible with the following cache configurations:
-
Caches without backups.
-
Local caches.
-
Near caches.
-
Caches that use "read-through" mode.
Transactional Caches
All values across the topology are replaced with the latest version.
-
Automatically for transactions that have
TransactionConcurrency.OPTIMISTIC
concurrency mode orTransactionIsolation.READ_COMMITTED
isolation level -
at the commit() phase for transactions that have
TransactionConcurrency.PESSIMISTIC
concurrency mode and isolation level other thanTransactionIsolation.READ_COMMITTED
When a backup inconsistency is detected, Ignite will generate a consistency violation event (if the event is enabled in the configuration). You can listen to this event to get notified about inconsistency issues. Refer to the Working with Events section for the information on how to listen to events.
Read Repair does not guarantee "all copies check" in case value already cached inside the transaction. For example, in case you use !TransactionIsolation.READ_COMMITTED isolation mode and already read the value or performed a write, you’ll gain the cached value.
Atomic Caches
The consistency violation exception is thrown if differences are found.
Due to the nature of the atomic cache, false-positive results can be observed. For example, an attempt to check consistency under load may lead to consistency violation exception. By default, the implementation tries to check the given key three times. The number of attempts can be changed by setting IGNITE_NEAR_GET_MAX_REMAPS
system property.
Be aware that the consistency violation event will not be fired for atomic caches.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.