Modelling replication protocols with actions and constraints Karthikeyan Bhargavan, Marc Shapiro, Fabrice le Fessant Microsoft Research Ltd., Cambridge, U.K. 15 April 2003 Abstract We describe a number of replication algorithms in a unified model based on actions and constraints. Applications submit actions (operations) to be executed and arbitrary constraints on those actions; object invariants are also expressed as constraints; and replication protocols impose further constraints. Any given site executes the actions it knows according to a schedule that satisfies the constraints. The goal of a protocol is to add constraints until its schedules are consistent. A replication protocol is consistent, if it maintains a local safety invariant (schedules are sound), a global invariant (local decisions do not conflict), and is live (every action eventually stabilises at all sites).
Contact: Marc Shapiro, Microsoft Research Ltd, 7 JJ Thomson Ave., Cambridge CB3 0FB, United Kingdom. Tel. +44 1223 479 739, fax +44 1223 479 999. Email:
[email protected] Paper to be considered for both regular and brief announcement tracks. None of the authors is a student.
1
Introduction
Replication has been studied extensively [13]. A number of replication protocols have been proposed, but it is not always obvious what properties they guarantee, or how they compare with one another. This work helps understand the differences by proposing a simple model, and a formal, compact definition of consistency. Our model describes a replicated system with actions and constraints. Actions are submitted for execution by clients at different sites. Each site executes the actions it knows, in some sequential schedule. To ensure correctness, schedules are restricted by safety conditions that we model as constraints. Messages propagate the knowledge of actions and constraints across sites. A single constraint language expresses three different purposes: user intents, for instance “run action β only if α succeeds;” data semantics, for instance “action α conflicts with action β,” and replication protocol decisions, for instance “serialise action α before β.” In addition to propagating actions, a replication protocol also makes decisions that strengthen the mix of constraints in order to ensure consistency is ensured. Our constraint model is small but sufficient to express a number of interesting semantics. The model is completely asynchronous and makes very few assumptions about the nature of the distributed system, of the applications, of the replicated data, and of the replication protocol. We can describe both centralised or peerto-peer systems; optimistic or pessimistic concurrency control; and both lockbased and time-based protocols. Consistency is broken down into three properties: (i) the local soundness property that schedules satisfy the constraints, (ii) the global safety property that a site’s constraints do not conflict with another’s, and (iii) the liveness property that actions eventually stablise. In this paper we describe four very different replication protocols from the literature. In so doing, we formalise their differing assumptions and exhibit their core mechanisms. We show that they all satisfy the above properties. Here is the outline for the rest of the paper. In Section 2 we describe our model. The next sections presents the models for four protocols and proves their consistency: Golding’s TSAE in Section 3, the two versions of Fekete et al.’s ESDS in Section 4 (Commutative ESDS) and Section 5 (Non-Commutative ESDS), and Terry et al.’s Bayou in Section 6. We compare our model with the state of the art in Section 7. Section 8 concludes.
2
Model
We now describe our model, very tersely. We refer the reader interested in a more complete treatment to a separate report [15].
1
2.1
Actions, schedules, constraints and multilogs
We assume a shared data set replicated over a number of sites i, j, . . . . Clients (not modeled) submit, i.e., make known, actions and constraints to these sites.1 We note A the set of all actions α, β, γ, and ↔ (pronounced NonCommuting) the inverse of the usual commutativity relation over A × A. A site executes the actions it knows in some serial schedule. Every schedule starts with special action init . To simplify the model we assume a schedule extends to the beginning of time, and model the current state of a site by its schedule. Two schedules are equivalent if they differ only by swapping commuting actions. Two schedules have a common prefix P if they both start with a prefix equivalent to P . An action α contains some executable code α.exec and a precondition α.precond . If the α.precond is true in the current state, α.exec executes in the schedule. We explicitly mark a schedule as not executing some action β by including the non-action placeholder β. The set of non-actions is A. A non-action commutes with every action and every other non-action. By convention α.precond is true and executing α.exec has no effect. The schedules that may be executed at a site are restricted by the constraints. The constraint language exposed in this paper is voluntarily limited. We support an ordering constraint → ⊆ A × A (pronounced Before), an implication constraint ⊲ ⊆ [A ∪ A] × [A ∪ A] (pronounced MustHave), and general predicates with preconditions.2 Constraints are defined formally as soundness conditions on schedules (see Section 2.3). MustHave, like implication, is reflexive, transitive and if α ⊲ β then β ⊲ α. The basic constraints can be combined to express common idioms such as causal dependency (α → β ∧ β ⊲ α), atomicity (α ⊲ β ∧ β ⊲ α), mutual exclusion (α → β ∧ β → α, which is equivalent to α ⊲ β), etc.3 A site records the actions and constraints it knows in what we call a multilog.4 Sites send messages to one another containing their multilogs. The multilog of site i at time t is noted Mi,t = (Ki,t , ⊲i,t , →i,t ), where K ⊆ A is the set of known actions and the other two terms are the known MustHave and Before constraints. When there is no ambiguity, we omit i and t. When a client submits a new action α or constraint c, the site adds it to the local multilog M , e.g., K := K ∪ {α} or ⊲ := ⊲ ∪ {c}. When a site receives a message containing a multilog M ′ from some other site it adds the information to its own multilog M , viz., M := M ∪ M ′ , where we define M ∪ M ′ as (K ∪ K ′ , ⊲ ∪ ⊲′ , → ∪ →′ ). 1 Each operation submitted by a client constitutes a separate action. For instance “increment x by 10; decrement y by 1 if positive; increment x by 10” would record as three different actions. 2 Any Before constraint could be folded into the precondition. However it is useful to make Before constraints explicit as this is a very common idiom, and enables efficient scheduling [10]. 3 See Appendix A for a definition of ACID transactions. 4 Recording local actions is often called logging. We call this data structure ‘multilog’ to stress that it is not totally ordered and that the actions it contains were submitted at several sites.
2
We assume that a multilog does not lose information, i.e., it can only grow over time.
2.2
Interesting subsets
An action α such that init ⊲ α must be in every schedule, it is said guaranteed, and we define Guaranteed (M ) = {x ∈ K|init ⊲ x}. Conversely the set of actions that cannot be in any schedule is Dead (M ) = {x ∈ K|init ⊲ x}.5 An action that is either guaranteed or dead is said settled. Serialised actions are the known ones whose order has been definitely set with respect to non-commuting actions (possibly not yet known): Serialised (M ) = {x ∈ K|∀y ∈ A : x ↔ y ⇒ [x → y ∨ y → x ∨ y ∈ Dead (M )]}. An action is said stable when its outcome is definite: it is settled, and, if guaranteed, it is serialised and actions that precede it are themselves stable. Action α ∈ Stable(M ), M = (K, ⊲, →), if and only if: α = init ∨α ∈ Dead (M )∨ [ α ∈ Guaranteed (M ) ∧ α ∈ Serialised (M ) ∧ ∀β ∈ A : β → α ⇒ β ∈ Stable(M ) ] These sets are all monotonically non-shrinking. If actions are eventually settled and serialised, they eventually stabilise.
2.3
Soundness
A schedule generated from M is said sound if it respects the constraints of M . Formally: A schedule S is generated from M = (K, ⊲, →) and is sound if and only if S = init α β γ . . . such that x∈K ⇔x∈S⊗x∈S ∧ ∀x, y ∈ S, x → y ⇒ S = . . . x . . . y . . . ∧ ∀x ∈ S, y ∈ A ∪ A, x ⊲ y ⇒ y ∈ S ∧ ∀x ∈ S, x.precond is true where ⊗ represents exclusive or. Note that soundness does not guarantee that all known actions are executed. Indeed scheduling action α might preclude some β from executing (e.g., if mutually exclusive). If it is possible to generate a sound schedule from multilog M , we say M is a sound multilog. A sound multilog has the following interesting properties: (1) Guaranteed (M ) ∩ Dead (M ) = Ø, (2) → is acyclic in Guaranteed (M ), and (3) some schedule executes where all α.precond succeed. An unsound multilog remains unsound thereafter.
2.4
Consistency
Intuitively, consistency means that sites compute the same values for their replicas. The following safety condition captures this intuition: at any time t, there 5 For instance, if α and β are mutually exclusive, then α ∈ Guaranteed (M ) ⇔ β ∈ Dead(M ).
3
exists a common prefix P (t) of all sound schedules generated by Mi,t′ , for all sites i and all times t′ ≥ t. We add a liveness property: for any submitted action α, eventually either α or α is in P (t). This definition is general, as it works even for aynchronous and optimistic systems. The following three properties (a local safety property, a global safety property, and a liveness property) together imply consistency: Soundness At every site i, at any time t, multilog Mi,t is sound. Mergeability For any two sites i, i′ , and any times t, t′ , Mi,t ∪ Mi′ ,t′ is sound. Stabilisation Actions eventually stabilise everywhere: ∀α ∈ Ki,t , ∀j, ∃t′ ≥ t : α ∈ Stable(Mj,t′ ). In particular, every stable action eventually reaches the common prefix.
2.5
Consistent replication protocols
A replication protocol consists of a set of transitions that modify the global state. This state consists of a set of pending messages M, and at each site i, a multilog Mi = (Ki , ⊲i , →i ).6 For example, a transition could allow a user to submit an action at a site, or send the local multilog to another site. An execution of the protocol is an infinite sequence of transitions. Protocols make decisions on submitted actions by adding constraints to multilogs. For instance if two actions are mutually exclusive, the protocol must decide which one to execute. If two non-commuting actions are not ordered initially, the protocol must come up with an ordering. In a decentralised setting, it is difficult to conciliate adding constraints online and maintaining mergeability. Sites may not take opposing decisions. This forbids cases such as site i accepting α when site j rejects it, or site i ordering α before β when site j does the reverse. In the following sections, we will describe four different consistency protocols in our model, and briefly explain why these protocols are correct. A consistency protocol is correct in our model if it verifies the following two theorems: Theorem 1 (Safety) All the transitions of the protocol maintain soundness and mergeability. Theorem 2 (Liveness) Every action eventually stabilises in fair executions. The second theorem requires fair executions which are defined as follows: Assumption 1 (Fairness) A fair execution is an infinite execution where any transition enabled an infinite number of times is executed an infinite number of times. In particular, all sites must keep sending and receiving multilogs from all other sites, ensuring that actions are eventually propagated everywhere in the system. 6 Hereafter
the time argument is implicit.
4
3
Timestamped Anti-Entropy (TSAE)
TSAE [6] is an optimistic replication protocol using timestamps. The protocol assigns strictly increasing unique timestamps to actions as they are submitted. Sites engage in pairwise “anti-entropy” sessions, aiming to merge their multilogs. First they compare their summary timestamp vectors (which summarise the known actions submitted at other sites), then they send each other the missing actions. Furthermore, each site maintains an Ack vector, containing for every site the oldest timestamp in their summary. An action with a timestamp older than the oldest entry in Ack is known by all other sites and may be safely removed from the multilog. To model TSAE, we add to the action set a discrete infinite set of timestamp no-op actions tn , totally ordered, and each site i is assigned an infinite and disjoint subset Ti of these timestamps. The TSAE protocol makes the following assumptions: no action excludes another, ∀α ∈ A, α.precond is true, and ∀α, β ∈ A, α ↔ β. Initially, the global state is Ki = {init}, ⊲i = Ø, →i = {tn → tm |n < m}, M = Ø. The four transitions in TSAE are: Submit(i, α): Precondition: α ∈ Ai \ Ki , tn ∈ Ti , ∀tm ∈ Ti ∩ Ki , n > m Effect: Ki := Ki ∪ {α, tn , tn+1 } ⊲i := ⊲i ∪ {init ⊲ α, init ⊲ tn , init ⊲ tn+1 } →i := →i ∪{tn → α, α → tn+1 } Send(j, Mi ): Send the multilog to another site. Effect: M := M ∪ {(j, Mi )} Receive(i, M ′): Precondition: (i, M ′ ) ∈ M Effect: Mi := Mi ∪ M ′ ; M := M \ {(i, M ′ )}. T ick(i): Increase the timestamp counter Precondition: tn ∈ Ti , ∀tm ∈ Ti ∩ Ki , n > m Effect: Ki := Ki ∪ {tn } The published TSAE protocol only contains the first three transitions. We added the T ick transition to make the protocol live, since a site may stop submitting new actions and thus, prevent stabilisation of new actions in the regular TSAE. The TSAE protocol verifies theorems 1 and 2. Moreover, any action removed from a log by a site using the Ack vector mechanism is also stable in our model.
4
Commutative ESDS
This section describes the commutative version of the Eventually Serialisable Data Service protocol [4, Section 8.3]. In this protocol, which we call C-ESDS, 5
operations are assumed to commute, except when an operation α explicitly indicates causal dependencies on a set of operations α.prev . C-ESDS ensures that the schedules executed at each replica obey these dependencies, and replicas eventually converge. The order in which actions are scheduled is determined by labels that are assigned, in causal order, to guaranteed actions. In our model, the causal dependencies between operations can be easily translated: for all β ∈ α.prev : β → α ∧ α ⊲ β. All other actions are commuting: for all α, β, α ↔ β if and only if α ∈ β.prev or β ∈ α.prev. Preconditions are void: ∀α ∈ A, α.precond = true. No action excludes another. The initial state of the protocol is: M = Ø, Ki = {init }, ⊲i = Ø, →i = Ø. The C-ESDS protocol has the following transitions: Submit(i, α): Submit an action and add its causal constraints. Precondition: α ∈ Ai , α ∈ / Ki , if β ∈ α.prev then α 6∈ β.prev , if β ∈ α.prev then for some site j, β ∈ Kj . Effect: Ki := Ki ∪ {α}, ⊲i := ⊲i ∪ {α ⊲ β : β ∈ α.prev}, →i := →i ∪{β → α : β ∈ α.prev}. Send(j, Mi ), Receive(i, M ′): Same as in TSAE. Accept(i, α): If all causal precedents are known, ensure action α is guaranteed at site i. Precondition: α ∈ Ki and α.prev ⊆ Guaranteed(Mi ), Effect: ⊲i := ⊲i ∪ {init ⊲ α}. In the Submit transition, we have added two pre-conditions that describe valid inputs to C-ESDS. First, we assume that there are no causal loops (α ∈ β.prev ∧ β ∈ α.prev does not occur). Second, we assume that all causal precedents of an action have already been submitted at some replica. The first condition is needed for safety (Theorem 1); the second is needed for liveness (Theorem 2). To see that the protocol satisfies Theorem 1, note that the only constraints ever added by the protocol are causal constraints and action guarantees. Since actions have no conflicts, and there are no causal loops, all multilogs are sound and mergeable. For Theorem 2, note that actions become stable as soon as they are guaranteed. Reasoning within our model clarifies the requirements of C-ESDS and suggests two simplifications to the protocol specified by Fekete et al. First, an action is stable as soon as its antecedents are guaranteed at the local site; it is not necessary to wait, as they do, for the action to be stable at other sites. Second, all local orders compatible with the initial constraints are equivalent, and the global total order they compute is unnecessary.
6
5
Non-Commutative ESDS
In the full ESDS protocol, which we call NC-ESDS [4], actions are assumed not to commute. Therefore all sites must execute the exact same schedule. To ensure an action is guaranteed, NC-ESDS follows the same procedure as C-ESDS. An action is guaranteed when its antecedents are guaranteed locally; however, in contrast to the commutative version, this does not imply the action is stable since all actions must also be ordered. Every site assigns a label to each guaranteed action; the effective label of an action is the minimum of all these labels. Actions are scheduled in the order of increasing effective labels. To model NC-ESDS, as in TSAE, we add a discrete infinite set of no-op label actions, ln , that are totally ordered. To each site i and each action α we assign an infinite and disjoint subset Lα,i of these labels. Labels have no pre-conditions and commute with all regular actions. The initial state of the protocol is: M = Ø, Ki = {init }, ⊲i = Ø, →i = {ln → lm |n < m}. The protocol assumes there there are no mutual exclusion and α.precond is true for all actions. The transitions in NC-ESDS are: Submit(i, α), Send(j, Mi ), Receive(i, M ′): Same as in C-ESDS. Accept(i, α) : If all causal precedents exist, guarantee action α, and give it a new label ln ∈ Lα,i . α ∈ Ki , α.prev ⊆ Guaranteed (Mi ), Precondition: ln ∈ Lα,i , ∀lm ∈ Ki , n > m Effect: Ki := Ki ∪ {ln }, ⊲i := ⊲i ∪ {init ⊲ α, init ⊲ ln }, →i := →i ∪{α → ln } Stabilise(i, α) : If all labels for α have been received, then totally order α with respect to all actions. Precondition: for all j, there exists ln ∈ Ki such that ln ∈ Lα,j Effect: let L = {β : lm ∈ Lβ,j ∩ Ki and ∀ln ∈ Lα,k ∩ Ki : m < n}, →i :=→i ∪{β → α : β ∈ L} ∪ {α → β : β 6= α, β ∈ A \ L} Here, when a site guarantees an action it assigns a label to it. When all the labels for an action have been received, the Stabilise transition computes the effective label for the action and orders it with respect to all other actions; until then it is ordered only according to its causal dependencies. To see that NC-ESDS verifies the safety theorem, note that the causal constraints on actions induce a partial order which is extended to a total order when the effective labels are computed. So the constraints introduced by NCESDS never conflict. For liveness, we note that actions become stable as soon as Stabilise is executed, that is when all sites have guaranteed an action and communicated its label. This follows from the fairness assumption, and the liveness of C-ESDS.
7
6
Bayou
Bayou extends TSAE, such that an action’s original timestamp only orders it partially with respect at the submission site, and adds a primary-based commit protocol to test preconditions and to arbitrate conflicts. Each replicated object has a single primary site in Bayou, and each action operates on a single object. We map action α to the single primary site prim(α) that is the primary of the object on which α operates. Bayou assumes that actions with the same primary are non-commuting: ∀α, β ∈ A, α ↔ β ⇔ prim(α) = prim(β). Contrary to the previous protocols, an action precondition may fail in Bayou, stopping it from committing. We introduce the notation P rimary(Mi , j) = {α ∈ Ki \Dead(Mi ), prim(α) = j}, and Ai for the set of actions submitted at site i. Initially, M = Ø, Ki = {init }, ⊲i = Ø, →i = Ø. Bayou has the following transitions: Submit(i, α): Submit an action. Precondition: α ∈ Ai \ Ki . Effect: Ki := Ki ∪ {α} →i := →i ∪{β → α : β ∈ Ki ∩ Ai } Send(j, Mi ), Receive(i, M ′ ): Same as in TSAE. Accept(i, α): Accept an action on the primary site. Precondition: α ∈ P rimary(Mi , i) \ Guaranteed(Mi ), ∀β ∈ P rimary(Mi , i), (β 6→i α) ∨ β ∈ Guaranteed(Mi ) ∃S generated from Mi s.t. S ⊂ Guaranteed(Mi ), α.precond in Sα Effect: ⊲i := ⊲i ∪ {init ⊲ α} →i := →i ∪{β → α : β ∈ P rimary(Mi , i) ∩ Guaranteed(Mi )}∪ {α → β : β ∈ P rimary(Mi , i) \ Guaranteed(Mi )} Reject(i, α): Reject an action on the primary site. Precondition: α ∈ P rimary(Mi , i) \ Guaranteed(Mi ), ∀β ∈ P rimary(Mi , i), (β 6→i α) ∨ β ∈ Guaranteed(Mi ) ∃S generated from Mi s.t. S ⊂ Guaranteed(Mi ), ¬α.precond in Sα Effect: ⊲i := ⊲i ∪ {init ⊲ α} As the previous protocols, the Bayou protocol verifies Theorems 1 and 2. Indeed, only the primary can accept or reject actions, and accepted actions with the same primary are totally ordered, and this order respects the partial order between actions submitted on the same site.
8
7
Related work
There is a large body of work on replicated data; see for instance the survey by Saito and Shapiro [13]. The relations between consistency and ordering in distributed systems have been studied in the database community, in the context of serialisability, and by the distributed systems community, with conditions such as linearisability, sequential consistency, causal consistency, etc. In most such work, the only ordering relation is causal dependence, which we break down into simpler, reusable primitives. Similarly, we decompose high-level events, such as commit or abort, into more primitive ones. We also insist that non-commutativity relations between actions be explicit. Our object constraints, representing the concurrency control conditions on pairs of actions, are inspired by Herlihy [7], and by the compatibility tables of Schwarz and Spector [14]. Our precond predicate is inspired by Bayou [16]. Balasubramaniam and Pierce [1] propose a model of reconciliation in an optimistically replicated file system. Ramsey and Csirmaz [12] provide an operationbased specification that specifies rigorously the compatibility of pairs of operations. Object constraints capture similar information, as in our replicated file system RFS [10]. Our model has similarities with the Acta framework [2]. Our approach is more prescriptive: user and object constraints dictate what a particular execution must or must not do; our correctness conditions dictate what any consistent system must and must not do.
8
Conclusion
The motivation for this work was to understand the differences between existing replication systems and to design systems with new properties. We proposed a formal model for data replication systems that unifies user intents, object invariants and protocol execution under a unified abstraction, constraints. Previously [10] we had shown that a small set of constraints is sufficient to encode the semantics of a number of interesting applications. In this paper we used the same constraint language to describe replication protocols. The goal of a protocol is to add constraints until its schedules are consistent. We prove that a replication protocol that meets three operational requirements is consistent: soundness, mergeability, and stabilisation. We describe and compare four very different consistency protocols. The four protocols we describe in this paper all satisfy the requirements. In fact we were able to show that one of the protocols (C-ESDS) is much stronger than necessary with respect to its assumptions. Constraints enable to break down the behaviour of complex systems into very simple components, making them easier to understand and compare. This particular set of constraints works for us; it is by no means complete or unique. By focusing on the stable prefix of schedules and on eventual consistency, our model exposes some interesting similarities between pessimistic and opti-
9
mistic protocols. An optimistic protocol differs from a pessimistic one in that clients can observe the outcome of non-stable actions. Conversely, a consistent optimistic protocol has a stable core that in essence is a pessimistic protocol running in the background. Work items on our agenda include: extending the constraint repertoire to probabilistic and timed constraints, modelling partial replication, taking failures into account, and designing decentralised reconciliation protocols for groupware and e-commerce scenarios.
References [1] S. Balasubramaniam and B. C. Pierce. What is a file synchronizer? In Int. Conf. on Mobile Comp. and Netw. (MobiCom ’98). ACM/IEEE, Oct. 1998. [2] P. K. Chrysanthis and K. Ramamritham. Correctness criteria and concurrency control. In A. Sheth, A. K. Elmagarmid, and M. Rusinkiewicz, editors, Management of Heterogeneous and Autonomous Database Systems, chapter 10. Morgan-Kaufmann, 1998. [3] F. Fages. A constraint programming approach to log-based reconciliation problems for nomadic applications. In 6th Annual W. of the ERCIM Working Group on Constraints, Prague (Czech Republic), June 2001. [4] A. Fekete, D. Gupta, V. Luchangco, N. Lynch, and A. Shvartsman. Eventually-serializable data services. Theoretical Computer Science, 220(Special issue on Distributed Algorithms):113– 156, 1999. [5] M. Fisher, N. Lynch, and M. Patterson. Impossibility of distributed consensus with one faulty process. J. ACM, 32(2):274–382, Apr. 1985. [6] R. A. Golding. Weak-Consistency Group Communication and Membership. PhD thesis, University of California at Santa Cruz, Santa Cruz, CA (USA), Dec. 1992. [7] M. Herlihy. Apologizing versus asking permission: optimistic concurrency control for abstract data types. Commun. ACM, 15(1):96–124, 1990. [8] J. Holliday, D. Agrawal, and A. E. Abbadi. Partial database replication using epidemic communication. In 22th Int. Conf. on Distr. Comp. Sys. (ICDCS), pages 485–493, Vienna, Austria, July 2002. IEEE Computer Society. http://computer.org/proceedings/icdcs/1585/1585toc.htm. [9] P. R. Johnson and R. H. Thomas. The maintenance of duplicate databases. http://info. internet.isi.edu/in-notes/rfc/files/rfc677.txt, Jan. 1976. [10] N. Pregui¸ ca, M. Shapiro, and C. Matheson. Efficient semantics-aware reconciliation for optimistic write sharing. Technical Report MSR-TR-2002-52, Microsoft Research, Cambridge (UK), May 2002. [11] K. Ramamritham and P. K. Chrysanthis. A taxonomy of correctness criteria in database applications. VLDB Journal, 5(1):85–97, 1996. [12] N. Ramsey and E. Csirmaz. An algebraic approach to file synchronization. In 9th Foundations of Softw. Eng., pages 175–185, Austria, Sept. 2001. [13] Y. Saito and M. Shapiro. Replication: Optimistic approaches. Technical Report HPL-2002-33, Hewlett-Packard Laboratories, Mar. 2002. [14] P. M. Schwartz and A. Z. Spector. Synchronizing shared abstract types. ACM Trans. Comput. Syst., 2(3):223–250, Aug. 1984. [15] M. Shapiro, K. Bhargavan, and F. le Fessant. A constraint model of replication. Technical Report MSR-TR-2003-29, Microsoft Research, Cambridge, UK, 2003. [16] D. B. Terry, M. M. Theimer, K. Petersen, A. J. Demers, M. J. Spreitzer, and C. H. Hauser. Managing update conflicts in Bayou, a weakly connected replicated storage system. In Proc. 15th ACM Symp. on Op. Sys. Principles, Copper Mountain CO (USA), Dec. 1995. ACM SIGOPS.
10
A
ACID transactions
ACID transactions are defined as follows. A transaction is a set of actions T ⊆ A such that transactions are: (1) disjoint: T ∩ T ′ = Ø, (2) atomic: α, β ∈ T ⇒ α ⊲ β, and (3) serialisable (which implies isolation): ∀α, β ∈ T, α′ , β ′ ∈ T ′ , α → α′ ∧ β ↔ β ′ ⇒ β → β ′ . Durability follows from stability. This paper makes no further mention of transactions, as the protocols we analyse do not support them.
Acknowledgments Ralph Beckett was the first to suggest viewing reconciliation as a constraint solving problem. Fran¸cois Fages came up with Before and MustHave as the primitive constraints for reconciliation problems. Nuno Pregui¸ca, the author of the IceCube constraint engine, contributed greatly to the design of constraints. We benefited greatly from encouragements and contributions by Ken Wood and Tony Hoare.
11
