Consistency Guarantees

1
Consistency Guarantees
Prasun Dewan
Department of Computer Science University of
North Carolina dewan_at_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

3
Synchronization model

• Users submit operations in transactions

4
Synchronization systems

• Provide synchronization on behalf of applications

Consistency requirements
Consistency criteria
5
Consistency requirements criteria

• Consistency requirements
• specify the set of ideally allowable schedules.
• Users may concurrently add room reservations
  (that dont 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
consistency requirements
all possible schedules
consistency criteria
7
Traditional criteria serializability

• Concurrent transactions execute as if they were
  submitted one after the other.

all possible schedules
serializable schedules
8
Serializability
T1
T2
Serializable
R(d1)
R(d2)
Commuting operations can be reordered
W(d2)
W(d1)
R(d2) R(d1) W(d1) W(d1)
9
Serializability
T1
T2
Non serializable!
R(d1)
R(d1)
W(d1)
W(d1)

• 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
T1
T2
ls
ls slides
mkdir slides
mkdir notes

• Modeling ls as read and mkdir as write leads to
  previous, directory-independent, non-serializable
  case
• Using type-specific semantics leads to
  serializable case

11
Type-specific Serializability
T1
T2
ls
ls slides
mkdir slides
mkdir notes
ls ls slides mkdir slides mkdir notes
12
Validation Time

• Pessimistic
• Early
• Failure gt block
• Optimistic
• Late
• Failure gt abort

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
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

• Codas requirements

all possible schedules
Serializability
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 Approach
T1
T2
R(Drawing)
R (Drawing)
W (Rectangle)
W (Line)

• Assuming entire drawing read.
• Not serializable.

22
Liberal Approach
T1
T2
R(Rectangle)
R (Line)
W (Rectangle)
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

• ExampleRoom 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
merging
server
server
News, Grapevine, Bayou
Consistency Guarantees from Client Point of View
client
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