// Licensed to the Apache Software Foundation (ASF) under one or more
// contributor license agreements.  See the NOTICE file distributed with
// this work for additional information regarding copyright ownership.
// The ASF licenses this file to You under the Apache License, Version 2.0
// (the "License"); you may not use this file except in compliance with
// the License.  You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
= 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 {tilde}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:

[source, java]
----
include::{javaCodeDir}/BasicCacheOperations.java[tags=read-repair, indent=0]
----

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 link:https://ignite.apache.org/releases/{version}/javadoc/org/apache/ignite/events/EventType.html#EVT_CONSISTENCY_VIOLATION[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 link:events/listening-to-events[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.