distributed computing - "Eventual Consistency" vs "Strong Eventual Consistency" vs "Strong Consistency"? -

i came across concept of "strong eventual consistency" . supposed stronger "eventual consistency" weaker "strong consistency"? explain differences among these 3 concepts applicable examples?

http://en.wikipedia.org/wiki/eventual_consistency#strong_eventual_consistency http://en.wikipedia.org/wiki/conflict-free_replicated_data_type

many thanks.

disclaimer: text below should give rough idea differences among eventual consistency, strong eventual consistency , strong consistency. in way over-simplification. take them grain of salt ;)

---

first things first: when talk consistency refer scenario different entities (nodes) have own copy of data object. now, conflicts arise because each node can update own copy (e.g. because there clients, each 1 connected node, asking them so), if read data different nodes i'll see different values. eventual consistency (ec), strong eventual consistency (sec) , strong consistency (sc) come play.

eventual consistency conflicts can arise, nodes communicate each other changes solve conflicts, in time agree upon definitive value. thus, if no more changes applied data period, nodes agree in data value (i.e. agree) readers of data see same value.

example: 2 nodes , b (na , nb) have each 1 copy of string, update operations read() , write(string). let's each 1 has own client (clia , clib). let's both nodes store same value "joe", @ moment na updates "frank" (calls write("frank")). na tell nb value has been updated; both values differ conflict has arisen in can solved using policy (for example last-write-wins) nb updates record "frank". before conflict resolved clia , clib see different versions of data (the read() op result differ), both see same value again.

keep in mind if both nodes update value simultaneously conflict resolution still possible more complicated. sec shines.

strong eventual consistency special case of ec, valid data types.

let's assume data object shared counter, , updates made add(int value) , substract(int value) operations. in case, the order in apply updates not matter! if both na , nb start counter value of 0, , if na runs add(10) , nb runs substract(5) (simultaneosly), need send update operation each other without caring conflict resolution, ensured reach same value (remember that, in contrast, in previous example ec conflict resolution required)!

unfortunately sec applicable in data types , operations have specific properties (commutativity , others). such data types denoted conflict-free replicated data type (crdt) .

strong consistency quite different other two. here requirement upon update operations nodes agree on new value before making new value visible clients. way updates visible clients 'at same time', read same value @ times. introduces requirement blocking in update operations. both in ec , sec update operation on local copy updated (then operation broadcasted other nodes). here client update not return until nodes have agreed upon data value, , while done accesses copy of data 'locked' (so other clients reads blocked). in our example ec, if clia runs write("frank"), clia blocked until update agreed both na , nb, , made visible both clia , clib @ same time, i.e. read() operation should return same value on.