1. “Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System ” Distributed Systems Κωνσταντακοπούλου Τζένη

2. Introduction  Occasional – pair-wise communication (Arbitrary network connectively)  Clients can R/W to any replica without the need of explicit coordination with other replicas  Does not provide transparent replicated data support  Provide system support for application specific conflict detection and resolution

3. Bayou Applications Designed to support:  a variety of non-real-time collaborative applications  applications that might be used by individuals at different hosts at different times Examples:  Meeting room scheduler  Bibliographic database

4. Basic System Model  Each data collection is replicated in full at a number of servers  API supports R / W  Weakly consistent replication model  Session guarantees  Anti-entropy sessions

5. Conflict Detection and Resolution Storage systems must provide means for an application to specify its notion of a conflict along with its policy for resolving conflicts Resolution can vary according to the semantics of the application

6. Mechanism for automatic conflict detection and resolution:  Dependency checks  Write – Write conflicts  Read – Write conflicts  Can enforce arbitrary, multi-item integrity constrains on the data

7.  Merge procedures Included in each write operation Performed automatically at each serve Written by application programmers in the form of templates that are instantiated with the appropriate details filled in for each write Error logs Replicas are allowed to remain accessible

8. Replica Consistency All servers move towards eventual consistency because  Writes perform in the same, well- defined order  conflict detection and merge procedures are deterministic (servers resolve the same conflicts in the same manner)

9. Why ‘Undo’ and ‘Reapply’ ?  Writes order may differ from the required execution order  Servers immediately apply all known Writes to their replicas !!! Each server maintain a log of all Writes

10. Write stability and Commitment  A write operation becomes stable when the set of writes that precede it in the server’s Write log is fixed  We can identify each Write  A Write is stable (for the server) when it has the lower timestamp than all servers’ clocks

11.  Commit Procedure  Commit Procedure is used to speed up the rate at which updates stabilize in an environment where communication with some servers is not possible for extended periods of time  Primary commit scheme  Primary commit scheme, one server designated as primary takes responsibility for committing updates

12. Storage System Implementation Issues  Write Log Contains Writes that have been received by a Bayou Server, stored by their global committed or tentative order  Tuple Store A database that is obtained by executing the Writes in order and is used to process Read requests  Undo Log Facilitates rolling back tentative Writes that have been applied to the Tuple Store so that can be re-executed in a different order

14.  O Vector Each server maintains this timestamp vector to indicate in a compact way the omitted prefix of committed writes  C Vector Characterizes the state if the Tuple Store after executing the last committed Write in the Write Log  F Vector Characterizes the state after executing the last tentative Write in the Write Log !!! These timestamp vectors are not used for conflict detection !!! Enable server pairs to identify the sets of writes that need to be executed

15.  For recovery purposes: Full Write Log and a checkpoint of Tuple Store are maintained in stable storage  For performance purposes: Write Logs and the current Tuple Store are maintained in memory  Undo Log is maintained only in memory

16. Access Control A user may be granted:  R/W privileges to data collection  Server privileges to maintain a replica Mutual authentication and access control is based on public-key cryptography Every user possesses a public/private key pair and a set of digitally signed access control certificates

17. Types of certificates to grant, delegate and revoke access:  AC[PU,P,D ] certificate that grants privilege P on data D to user whose public key is PU  D[PU,C,PY] certificate signed by users whose public key is PY to delegate his privileges encoded in certificate C to another user whose public key is PU  R[C,PY] certificate signed by users whose public key is PY to revoke some user’s privileges encoded in certificate C

18. Conclusions  Non-transparency  Application- specific conflict detection  Per-write conflict resolves  Partial and multi-object updates  Tentative and stable resolutions  Security