Consistency Guarantees Prasun Dewan Department of Computer Science University of North Carolina [email protected]
Jan 18, 2018
Consistency Guarantees
Prasun Dewan
Department of Computer Science University of North Carolina
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