Aim: To study Data Centric and Client Centric Consistency Model Theory: Consistency model: A consistency model is a CONTRACT

between a DS data-store and its processes. If the processes agree to the rules, the data-store will perform properly and as advertised. Replication Data replication: common technique in distributed systems Reliability: a. If one replica is unavailable or crashes, use another b. Protect against corrupted data Performance: a. Scale with size of the distributed system (replicated web servers) b. Scale in geographically distributed systems (web proxies) Key issue: need to maintain consistency of replicated data: a. If one copy is modified, others become inconsistent Object Replication:

Approach 1: application is responsible for replication a. Application needs to handle consistency issues Approach 2: system (middleware) handles replication a. Consistency issues are handled by the middleware b. Simplifies application development but makes object-specific solutions harder

Requirements for Replication: Consistency: In many applications, we want that different clients making (read/write) requests to different replicas of the same logical data item should not obtain different results e.g.:

Above example is of updating a replicated database where Update 1 adds 100 euro to an account and Update 2 calculates and adds 1% interest to the same account. Due to network delays, the updates may come in different order, which may lead to an Inconsistent state.

Data-Centric Consistency Models: Consistency in terms of read and writes operations on shared data, called the data store A shared filesystem, memory space, database, etc. We assume that each process that can access data from the store has a local (or nearby) copy of the entire store Consistency in terms of read and write operations on shared data, called the data store. As shared filesystem, memory space, database, etc. We assume that each process that can access data from the store has a local (or nearby) copy of the entire store.

A data-store can be read from or written to by any process in a distributed system. A local copy of the data-store (replica) can support fast reads. However, a write to a local replica needs to be propagated to all remote replicas. Various consistency models help to understand the various mechanisms used to achieve and enable this.

Notation:

Processes execute to the right as time progresses. The notation W1(x).a means that the process wrote the value a to the variable x. The notation R2(x).a means that the process read the value a from the variable x. The subscript is often dropped.

Types of Consistency: 1. Strict Consistency: Any read always returns the result of the most recent write Implicitly assumes the presence of a global clock A write is immediately visible to all processes Difficult to achieve in real systems as network delays can be variable Update is performed at all copies as a single atomic operation. Problem: updating all replicas at once hurts the performance and scalability. Solution: loosen the consistency constraints.

2. Sequential Consistency: The result of any execution is the same as if the (read and write) operations by all processes on the data store were executed in some sequential order and the operations of each individual process appear in this sequence in the order specified by its program. 3. Causal Consistency: Writes that are potentially causally related must be seen by all processes in the same order. Concurrent writes may be seen in a different order on different machines. 4. Client-Centric Consistency Model: Concurrent processes may be simultaneously updating the data store, and that it is necessary to provide consistency in the face of such concurrency. For example, in the case of objectbased entry consistency, the data store guarantees that when an object is called, the calling process is provided with a copy of the object that reflects all changes to the object that have been made so far, possibly by other processes. During the call, it is also guaranteed that no other process can interfere that is, mutual exclusive access is provided to the calling process. Being able to handle concurrent operations on shared data while maintaining sequential consistency is fundamental to distributed systems. For performance reasons, sequential consistency may possibly be guaranteed only when processes use synchronization mechanisms such as transactions or locks. The previously studied consistency models concern themselves with maintaining a consistent (globally accessible) data-store in the presence of concurrent read/write operations. Another class of distributed datastore is that which is characterized by the lack of simultaneous updates.

Here, the emphasis is more on maintaining a consistent view of things for the individual client process that is currently operating on the data-store. This is called client-centric consistency

We describe client-centric consistency models with the following notation: -xi[t] is the version of data item x at local copy Li at time t -WS(xi[t]) is the set of write operations at Li that have taken place since initialization (resulting in xi[t]) -If operations in WS(xi[t1]) have also been performed at local copy Lj at a later time t2, we have WS(xi[t1];xj[t2])

5. Monotonic Read Consistency: If a process reads the value of a data item x, any successive read operation on x by that process will always return that same value or a more recent value (i.e. a process can never see older version of things it has already read) Sequence (a) satisfies monotonic read consistency, but sequence (b) does not

Fig.: Client-Centric Consistency Model

A mobile user may access different replicas of a distributed database at different times. This type of behavior implies the need for a view of consistency that provides guarantees for single client regarding accesses to the data store Assumptions: Lack of simultaneous updates Most operations involve reading data No write-write conflicts, only read-write ones

6. Eventual Consistency: If no updates take place for a long time, all replicas will gradually become consistent. Different Eventual Consistency Models: Monotonic-read Consistency: If a process reads the value of a data item x, any successive read operation on x by that process will always return that same value or a more recent value. Monotonic-write Consistency: A write operation by a process on a data item x is completed before any successive write operation on x by the same process. Read-your-writes Consistency: The effect of a write operation by a process on data item x will always be seen by a successive read operation on x by the same process. Writes-follow-reads Consistency: A write operation by a process on a data item x following a previous read operation on x by the same process is guaranteed to take place on the same or a more recent value of x that was used.

Conclusion: Thus we have successfully studied Data centric and Client centric consistency models.