Agreeing to Agree: Conflict Resolution for Optimistically Replicated Data

Abstract

Current techniques for reconciling disconnected changes to optimistically replicated data often use version vectors or related mechanisms to track causal histories. This allows the system to tell whether the value at one replica dominates another or whether the two replicas are in conflict. However, current algorithms do not provide entirely satisfactory ways of repairing conflicts. The usual approach is to introduce fresh events into the causal history, even in situations where the causally independent values at the two replicas are actually equal. In some scenarios these events may later conflict with each other or with further updates, slowing or even preventing convergence of the whole system.To address this issue, we enrich the set of possible actions at a replica to include a notion of explicit conflict resolution between existing events, where the user at a replica declares that one set of events dominates another, or that a set of events are equivalent. We precisely specify the behavior of this refined replication framework from a user's point of view and show that, if communication is assumed to be "reciprocal" (with pairs of replicas exchanging information about their current states), then this specification can be implemented by an algorithm with the property that the information stored at any replica and the sizes of the messages sent between replicas are bounded by a polynomial function of the number of replicas in the system.

Exploiting schemas in data synchronization

“…In this case o = o r , a = a r , and b = b r and since these are assembled as the concatenation of the results of each recursive call, we have o = ⊥, a = ⊥, and b = ⊥ (recall the difference between the empty tree and the missing tree). It follows directly that a ∼ a , b ∼ b , a ∼ b , o ∼ a , and o ∼ b , which immediately satisfies local safety conditions (1), (2). Local safety condition (3) is satisfied because there cannot be a conflict at the root: there is no local conflict because o = X and a ∼ b, and there is no schema domain conflict because mdom(o, a, b) = dom(a r ) ∈ doms(S) and mdom(o, b, a) = dom(b r ) ∈ doms(S).…”

“…(1) (S,o,a,b,X , a, b), (4) (S, o, a, o, a, a, a), (2) (S, o, a, a, a, a, a), (S, o, o, b, b, b, b), (6) (S,o,a,⊥, ⊥, ⊥, ⊥), assuming a < o.…”

“…We cache this final merged state, o , at the end of each synchronization, to use as the o input for the next synchronization. 2 Schematically, the synchronizer may be visualized like the diagram on the left of Fig. 1.…”

“…Our algorithm generalizes straightforwardly to n simultaneously connected replicas, but the more realistic case where only a subset of the replicas may be connected at any given moment poses additional challenges. Some progress in this area is reported in[2] 2. In a multi-replica system, an appropriate "last shared state" would instead be calculated from the causal history of the system.…”

Interval Tree Clocks

“…We refer the interested reader to the survey in [22] and to the historical notes in [4]. After an initial focus on message passing systems, recent developments have improved causality tracking for replicated data: they addressed efficient coding for groups of related objects [14]; bounded representation of version vectors [1]; and the semantics of reconciliation [10].…”