1. Consistency Guarantees Prasun Dewan Department of Computer Science University of North Carolina dewan@unc.edu

2. 2 Understanding Coda Directory Merging Semantics n Operations u add(d, e) u del(d, e) u mod(d, attr, val ) n Conficts u Client: add(d, e), uncached e existed on server at hoard time or server did add(d, e) subsequently u Client: mod(a1, v1), Server: mod(a2, v2) u Client: modified e, Server: deleted e F Or vice versa Guarantees?

3. 3 Synchronization model Shared data User 1User 2 Synchronization logic (BeginTransaction Operation* EndTransaction)* ÊUsers submit operations in transactions Operations are validated w.r.t. concurrent operations Ë Schedules (interleaved transactions)

4. 4 Synchronization systems n Provide synchronization on behalf of applications Shared data Application User 1User 2 Synchronization system Consistency requirements Consistency criteria

5. 5 Consistency requirements & criteria n Consistency requirements: u specify the set of ideally allowable schedules. u “Users may concurrently add room reservations (that don’t overlap), but may not concurrently change the same reservation.” n Consistency criteria: u specify the set of actually allowed schedules. u “Users must access the set of reservations one at a time.”

6. 6 Consistency Criteria vs. Requirements consistency requirements consistency criteria all possible schedules

7. 7 Traditional criteria: serializability n Concurrent transactions execute as if they were submitted one after the other. serializable schedules all possible schedules

8. 8 Serializability T1 R(d1) W(d1) T2 R(d2) W(d2) R(d2) R(d1) W(d1) W(d1) Commuting operations can be reordered =R(d1) R(d2) W(d1) W(d1) =R(d2) W(d2) R(d1) W(d1) Serializable

9. 9 Serializability T1 R(d1) W(d1) T2 R(d1) W(d1) Non serializable! n R-W Serializability u R-R operations commute and hence can be reordered. u R-W, and W-W do not commute and hence cannot be reordered. Cause R-W and W-W conflicts in non- serializable transactions

10. 10 Serializability n Modeling ls as read and mkdir as write leads to previous, directory-independent, non-serializable case n Using type-specific semantics leads to serializable case T1 ls mkdir notes T2 ls slides mkdir slides (R dir) (W dir) (R dir) (W dir)

11. 11 Type-specific Serializability T1 ls mkdir notes T2 ls slides mkdir slides ls ls slides mkdir slides mkdir notes = ls ls slides mkdir notes mkdir slides = ls mkdir notes ls slides mkdir slides

12. 12 Validation Time n Pessimistic u Early u Failure => block n Optimistic u Late u Failure => abort

13. 13 Early vs. late validation Early validation  Per-operation checking and communication overhead  No compression possible. Prevents inconsistency. Tight coupling: incremental results shared  Not functional if disconnected.  Unless we lock very conservatively, limiting concurrency. Late validation No per-operation checking, communication overhead Compression possible.  Inconsistency possible. Allows parallel development. Functional when disconnected.

14. 14 Understanding Coda Transactions n In strongly connected (hoarding) state u checks done incrementally, hence pessimistic n In disconnected (emulation) stage u checks done later at merge time, hence optimistic? F read operations not logged Not clear what user has read in say an LS assumed stale data ok, ignoring R-W conflicts F Type-specific W-W conflict detection for directories F No aborts because interactive transaction, user fixes conflicts F Not serializable, consistency not guaranteed! weak consistency works in many (but not all) cases - insight borrowed from News and Lotus Notes

15. 15 Coda Synchronization Coda’s requirements Serializability all possible schedules

16. 16 Weak Requirements not unique to Mobility n In strongly connected replicated systems also writes may not be propagated instantly u stale data in out of date replicas to F to improve performance u a single application may see different values in different servers u NFS, Sprite, AFS F In NFS 60 second window, 0.34% of opens result in stale data u In Mobile computing, problem exacerbated

17. 17 The problem of logging reads n In interactive application, not clear what user has read. n Probably reason for lack of read logs in Coda and other systems.

18. 18 Concurrent Drawing

19. 19 Concurrent Drawing

20. 20 Concurrent Drawing

21. 21 Conservative Approach T1 R(Drawing) W (Rectangle) T2 R (Drawing) W (Line) Assuming entire drawing read. Not serializable.

22. 22 Liberal Approach T1 R(Rectangle) W (Rectangle) T2 R (Line) W (Line) Assuming only modified objects read. Serializable.

23. 23 The problem of logging reads n In interactive application, not clear what user has read. n Coda, Sync and other systems take liberal approach, not keeping read logs. n Strict serializability would require conservative approach. n TACT and Bayou provide in between solution.

24. 24 TACT n Each write operation associated with a list of objects it depends on. n TACT can check if dependees have been changed.

25. 25 Bayou approach n Each write operation essentially associated with a user- provided boolean script that works on the values of the remote replicas. n Script called dependency check, used to determine if conflict

26. 26 Example n Example:Room reservation for time t1-t2 boolean dependency_check() { return no-one else has reserved a room t1-t2 }

27. 27 Example details

28. 28 TACT vs. Bayou n TACT script easier to write. n Bayou script more flexible - rather than checking if dependee in remote replica has changed, it can see if its value is within a particular range.

29. 29 Flexible detection of R-W Conflicts n Dependency check verifies values on which the write depended still hold. n But is very heavyweight u imagine writing a script for each kind of drawing operation.

30. 30 Guarantees with Two-level P2P server merging client News, Grapevine, Bayou Consistency Guarantees from Client Point of View

31. 31 Bayou Requirements Weaker than Serializability n Session-dependent requirements. n Constrain behavior of possibly disconnected replicated systems. n Session: u A series of successive actions taken by an application

32. 32 Read your own writes n Read returns previous written or later value in a session. Prevents: u Changed password at one server, type of new password causes error because another server contacted that has old password. u Deleted mail message at local server, but refresh caused reappearance of message from an out of date remote server. n Servers accessed in a session must be chosen appropriately to implement this requirement.

33. 33 Monotonic Reads n Monotonic reads. Read successively newer values in a session. Prevents: u Successive refreshes of calendar make recently added meetings disappear. u Newly displayed mail message disappears when accessed. n Severs chosen appropriately to meet requirement.

34. 34 Write follows reads n Writes made by a session at each replica follow writes (made by that or other sessions) that were read by previous reads in that session. n Preserves causality. Prevents: u Correction made to bibliographic item seen by all servers. u Replies to articles seen after original. n Order of actions chosen appropriately at a server, using logical time stamps

35. 35 Monotonic Writes n Successive writes by a session are not reordered at any server. n Prevents: u Successive file saves to be re-ordered at any server. u Updates library code and then application, but server receives latter before former. n Order of actions chosen appropriately using logical time stamps.

36. 36 Implementation n Read your own writes u When read is issued, session manager selects server that has applied your writes. n Monotonic reads u Similar. Select server that has written previously read values. n Writes follow reads and monotonic writes. u Writes are propagated in order. F Grapevine used mail, which can send out of order. u Writes are applied in order of timestamps at a replica. F Causal broadcast techniques

37. 37 Guarantees do imply serializability? n Concurrent operations (not related by causality) must be merged through application-defined merge procedures