Chapter 6: Consistency and replication
Replication of data is very important in
distributed systems Two reasons for replication: reliability and performance
PROBLEM: Will lead to consistency problems (the copies are not alike). Before replicating a remote object across several machines: HAVE TO PROTECT THE OBJECT AGAINST SIMULTANEOUS ACCESS BY MULTIPLE CLIENTS. Two solutions to this problem: 1: Object itself can handle concurrent invocation (declaring object`s methods to be syncronized) 2: The server where the object is, gets the responebility for the concurrency control. Additional synchronization is needed for the concurrent invocations.
Need to synchronize all replicas:
CONSISTENCY MODELS:
Is a contract between processes and the data store. The data store defines precisely what the results of the read and write operations are when it comes to CONSISTENCY. Strong:
Causally related: Read follows later than write Concurrent (entydig)( may be seen in different order on different machines): Opposite of Causally (assosiasjon)( must be seen by all processes in the same order) Weak: (Synchronization occurs only when shared data is locked and unlocked)
SEQUENTIAL IS THE ONLY ONE THE PROGRAMMERS LIKE. CLIENT-CENTRIC CONSISTENCY MODELS(client not server, this is why there is only one process, L1 and L2): Monotonic reads: Guarantees that the user sees all updates. Two local copies, one process. Reading and updating your calendar. Monotonic Writes: Take with you all the updates. A write operation must finish before the next write operation. Read your writes: Updating your webbrowser. You will see your updates after you have written them. You will not see your old writing. Writes follow reads: See reactions of posted only if you have the original posting.
|
|||||||||||||||||||||||||||