Edit

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 or TransactionIsolation.READ_COMMITTED isolation level
at the commit() phase for transactions that have TransactionConcurrency.PESSIMISTIC concurrency mode and isolation level other than TransactionIsolation.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.

© 2022 The Apache Software Foundation.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.