[id='conflicts-{context}']
= Conflicting Entries with Cross-Site Replication
Conflicting entries can occur with Active/Active site configurations if clients
write to the same entries at the same time but at different sites.

For example, client A writes to "k1" in **LON** at the same time that client B
writes to "k1" in **NYC**. In this case, "k1" has a different value in **LON**
than in **NYC**.

With synchronous replication, concurrent writes result in deadlocks because
both sites lock the same key in different orders. To resolve deadlocks, client
applications must wait until the locks time out.

With asynchronous replication, concurrent writes result in conflicting values
because sites replicate after entries are modified locally.  After replication occurs, there is no guarantee which value for "k1" exists at which site.

* Keys have conflicting values.

* One of the conflicting values is overwritten if sites do not replicate values at the same time. In this case, one of the values is lost and there is no guarantee which value is saved.

In all cases, inconsistencies in key values are resolved after the next
non-conflicting `put()` operation updates the value.

[NOTE]
====
There currently is no conflict resolution policy that client applications can
use to handle conflicts in asynchronous mode. However, conflict resolution
techniques are planned for a future {brandname} version.
====
