Consistency Guarantees

Prasun Dewan

Department of Computer Science University of North Carolina

dewan@unc.edu

2

Understanding Coda Directory Merging Semantics

Operations add(d, e) del(d, e) mod(d, attr, val )

Conficts Client: add(d, e), uncached e existed on server at

hoard time or server did add(d, e) subsequently Client: mod(a1, v1), Server: mod(a2, v2) Client: modified e, Server: deleted e

Or vice versa

Guarantees?

3

Synchronization model

Shareddata

User 1 User 2

Synchronization logic

(BeginTransaction Operation* EndTransaction)*

Users submit operations in transactions

Operations arevalidated w.r.t. concurrent operations

Schedules(interleaved transactions)

4

Synchronization systems Provide synchronization on behalf of applications

Shareddata

Application

User 1 User 2

Synchronization system

Consistency requirements

Consistency criteria

5

Consistency requirements & criteria

Consistency requirements: specify the set of ideally allowable schedules. “Users may concurrently add room

reservations (that don’t overlap), but may not concurrently change the same reservation.”

Consistency criteria: specify the set of actually allowed schedules. “Users must access the set of reservations

one at a time.”

6

Consistency Criteria vs. Requirements

consistencyrequirements

consistencycriteria

all possibleschedules

7

Traditional criteria: serializability Concurrent transactions execute as if they were

submitted one after the other.

serializableschedules

all possibleschedules

8

SerializabilityT1

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

SerializabilityT1

R(d1)

W(d1)

T2

R(d1)W(d1)

Non serializable!

R-W Serializability R-R operations commute and

hence can be reordered. 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

Serializability

Modeling ls as read and mkdir as write leads to previous, directory-independent, non-serializable case

Using type-specific semantics leads to serializable case

T1ls

mkdir notes

T2

ls slidesmkdir slides

(R dir)

(W dir)

(R dir)(W dir)

11

Type-specific SerializabilityT1

ls

mkdir notes

T2

ls slidesmkdir slides

ls ls slides mkdir slides mkdir notes

= ls ls slides mkdir notes mkdir slides

=

ls mkdir notes ls slides mkdir slides

12

Validation Time Pessimistic

Early Failure => block

Optimistic Late Failure => abort

13

Early vs. late validationEarly 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

Understanding Coda Transactions In strongly connected (hoarding) state

checks done incrementally, hence pessimistic In disconnected (emulation) stage

checks done later at merge time, hence optimistic? read operations not logged

• Not clear what user has read in say an LS• assumed stale data ok, ignoring R-W conflicts

Type-specific W-W conflict detection for directories No aborts

• because interactive transaction, user fixes conflicts Not serializable, consistency not guaranteed!

• weak consistency works in many (but not all) cases - insight borrowed from News and Lotus Notes

15

Coda Synchronization

Coda’s requirements

Serializabilityall possibleschedules

16

Weak Requirements not unique to Mobility

In strongly connected replicated systems also writes may not be propagated instantly stale data in out of date replicas to

to improve performance a single application may see different values in

different servers NFS, Sprite, AFS

In NFS 60 second window, 0.34% of opens result in stale data

In Mobile computing, problem exacerbated

17

The problem of logging reads In interactive application, not clear what user

has read. Probably reason for lack of read logs in Coda

and other systems.

18

Concurrent Drawing

19

Concurrent Drawing

20

Concurrent Drawing

21

Conservative ApproachT1

R(Drawing)

W (Rectangle)

T2

R (Drawing)

W (Line)

• Assuming entire drawing read.

• Not serializable.

22

Liberal ApproachT1

R(Rectangle)

W (Rectangle)

T2

R (Line)

W (Line)

• Assuming only modified objects read.

• Serializable.

23

The problem of logging reads In interactive application, not clear what user

has read. Coda, Sync and other systems take liberal

approach, not keeping read logs. Strict serializability would require conservative

approach. TACT and Bayou provide in between solution.

24

TACT Each write operation associated with a list of

objects it depends on. TACT can check if dependees have been

changed.

25

Bayou approach Each write operation essentially associated with a user-

provided boolean script that works on the values of the remote replicas.

Script called dependency check, used to determine if conflict

26

Example Example:Room reservation for time t1-t2

boolean dependency_check() { return no-one else has reserved a room t1-t2}

27

Example details

28

TACT vs. Bayou TACT script easier to write. 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

Flexible detection of R-W Conflicts Dependency check verifies values on which the

write depended still hold. But is very heavyweight

imagine writing a script for each kind of drawing operation.

30

Guarantees with Two-level P2P

server servermerging

client

News, Grapevine, Bayou

Consistency Guarantees from Client Point of View

31

Bayou Requirements Weaker than Serializability

Session-dependent requirements. Constrain behavior of possibly disconnected

replicated systems. Session:

A series of successive actions taken by an application

32

Read your own writes Read returns previous written or later value in a

session. Prevents: Changed password at one server, type of new

password causes error because another server contacted that has old password.

Deleted mail message at local server, but refresh caused reappearance of message from an out of date remote server.

Servers accessed in a session must be chosen appropriately to implement this requirement.

33

Monotonic Reads Monotonic reads. Read successively newer

values in a session. Prevents: Successive refreshes of calendar make recently

added meetings disappear. Newly displayed mail message disappears when

accessed. Severs chosen appropriately to meet

requirement.

34

Write follows reads 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.

Preserves causality. Prevents: Correction made to bibliographic item seen by all servers. Replies to articles seen after original.

Order of actions chosen appropriately at a server, using logical time stamps

35

Monotonic Writes Successive writes by a session are not reordered at

any server. Prevents:

Successive file saves to be re-ordered at any server. Updates library code and then application, but server

receives latter before former. Order of actions chosen appropriately using logical

time stamps.

36

Implementation Read your own writes

When read is issued, session manager selects server that has applied your writes.

Monotonic reads Similar. Select server that has written previously

read values. Writes follow reads and monotonic writes.

Writes are propagated in order. Grapevine used mail, which can send out of order.

Writes are applied in order of timestamps at a replica. Causal broadcast techniques

37

Guarantees do imply serializability? Concurrent operations (not related by causality)

must be merged through application-defined merge procedures