1. Client-Centric Consistency Models
Bhavana Pallepati

2. Client-Centric Consistency Models
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 data store 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.

3. Client Centric Consistency
In many cases concurrency appears only in restricted form.
In many applications most processes only read data.
Some degrees of inconsistency can be tolerate.
In some cases if for a long time no update takes place all replicas gradually become consistent.

4. Client-Centric Consistency
Provide guarantees about ordering of operations only for a single client, i.e.
Effects of an operations depend on the client performing it
Effects also depend on the history of client’s operations
Applied only when requested by the client
No guarantees concerning concurrent accesses by different clients
Assumption:
Clients can access different replicas, e.g. mobile users

5. Eventual Consistency - Eventual consistency for replicated data is fine if clients always access the same replica. Client centric consistency provides consistency guarantees for a single client with respect to the data stored by that client

6. Client-Centric Consistency Models
Clients access distributed data store using, generally, the local copy. Updates are eventually propagated to other copies. a) Monotonic read b) Monotonic write c) Read your writes d) Writes follow reads

7. Monotonic Reading
Definition: A DDS provides monotonic-read consistency if the following holds:
If process P reads the value of data item x, any successive read operation on x by that process will always return the same value or a more recent one (independently of the replica at location L where this new read will be done).

8. Example Systems
Distributed database with distributed and replicated user-mailboxes.
s can be inserted at any location.
However, updates are propagated in a lazy (i.e. on demand) fashion.

9. Example
The read operations performed by a single process P at two different local copies of the same data store.
A monotonic-read consistent data store
A data store that does not provide monotonic reads.

10. Monotonic Writing
Definition: DDS provides monotonic-write consistency if the following holds:
A write operation by process P on data item x is completed before any successive write operation on x by the same process P can take place.
Remark: Monotonic-writing ~ FIFO consistency
Only applies to writes from one client process P
Different clients -not requiring monotonic writing may see the writes of process P in any order

11. Example
The write operations performed by a single process P at two different local copies of the same data store
A monotonic-write consistent data store.
A data store that does not provide monotonic-write consistency.

12. Reading Your Writes
Definition: DDS provides “read your write” consistency if the following holds:
The effect of a write operation by a process P on a data item x at a location L will always be seen by a successive read operation by the same process.
Example of a missing read-your-write consistency:
Updating a website with an editor, if you want to view your updated website, you have to refresh it, otherwise the browser uses the old cached website content.
Updating passwords

13. Example A data store that provides read-your-writes consistency.
A data store that does not.

14. Writes Following Reads
Definition: DDS provides “ writes-follow-reads” consistency if the following holds:
A write operation by a process P on a data item x following a previous read by the same process, is guaranteed to take place on the same or even a more recent value of x, than the one having been read before.

15. Example A writes-follow-reads consistent data store
A data store that does not provide writes-follow-reads consistency

16. Implementing Client Centric Consistency
Naive Implementation (ignoring performance):
Each write gets a globally unique identifier
Identifier is assigned by the server that accepts this write operation for the first time
For each client two sets of write identifiers are maintained:
Read-set(client C) := RS(C)
{write-IDs relevant for the reads of this client C}
Write-set(client C) := WS(C)
{write-IDs having been performed by client C}

17. Implementing Monotonic Reads
When a client C performs a read at server S, that server is handed the client’s read set RS(C) to control whether all identified writes have taken place locally at server S. If not, server has to be updated before reading!

18. Implementing Monotonic Write
If client initiates a write on a server S, this server S gets the clients write-set in order to update server S. A write on this server is done according to the times stamped WID.
Having done the new write, client’s write-set is updated with this new write. The response time of a client might thus increase with an ever increasing write-set.
However, what to do if all the reader write-sets of a client get larger and larger?

19. Improving Efficiency with RS and WS
Major drawback: potential sizes of read- and write sets 
Group all write- and read-operations of a client in a so called session (mostly assigned with an application)
Every time a client closes its current session, all updates are propagated and these sets are deleted afterwards

20. Summary on Consistency Models
Choosing the right consistency model requires an analysis of the following trade- offs:
Consistency and redundancy
All replicas must be consistent
All replicas must contain full state
Reduced consistency  reduced reliability
Consistency and performance
Consistency requires extra work
Consistency requires extra communication
May result in loss of overall performance

21. Thank You