Last updated
To keep consistency between replicates, it's usually necessary to guarantee that conflicting operations are done in the same order.
Conflict-generating operations:
Read-write: reading and writing concurrent operations.
Write-write: two write operations.
Ensuring a global order in conflicting operations can be a time-consuming operation, which lowers the scalability potential.
Solution: lower the consistency requirements so that the necessity for global synchronism can be avoided.
A contract between a distributed data store and processes where the data store specifies precisely which are the results for a concurrent read and write operation.
Replicates can differ in their numeric value.
Replicates can differ in their relative immutability.
There can be differences in the number and order of update operations.
Unity of consistency -> specifies the unit of data over which there should be a consistency measure.
Each replicate has a vector clock.
B sends to A the operation in grey.
A permanently executed that operation.
Conit:
A has 3 pendant operations:
Deviation of order = 3.
A loses two of B's operations:
Max diff is 70 + 412 = (2, 482).
Numerical deviation of 482.
The result of any execution is the same if all operations of all processes are executed in the same sequential order, and the operations of each individual process appear in the program's specified order.
Writes that are related casuistically have to be seen by all processes in the same order. Concurrent writes can be seen in different orders by different processes.
Accesses to locks are consistent sequentially.
Accesses to locks are not permitted before all the previous writes have been completed.
Access to the data is not allowed until all previous accesses to locks have been completed.
It does not matter if the reads and writes of a set of operations are immediately known to all other processes. Only the effect of the set needs to be known.
