Eventual consistency

Eventual consistency

 A distributed system maintains copies of its data on multiple machines in order to provide high availability and scalability. When an application makes a change to a data item on one machine, that change has to be propagated to the other replicas. Since the change propagation is not instantaneous, there’s an interval of time during which some of the copies will have the most recent change, but others won’t. In other words, the copies will be mutually inconsistent. However, the change will eventually be propagated to all the copies, and hence the term “eventual consistency”. The term eventual consistency is simply an acknowledgement that there is an unbounded delay in propagating a change made on one machine to all the other copies. Eventual consistency is not meaningful or relevant in centralized (single copy) systems since there’s no need for propagation.

When choosing a NoSQL system, it is important to understand whether a choice of consistency policy is available. If the database system only supports eventual consistency, then the application will need to handle the possibility of reading stale (inconsistent) data. This is not as easy as it sounds since the responsibility of avoiding the “stale read” problem associated with eventual consistency is left to the application developer.

Links:
http://www.oracle.com/technetwork/consistency-explained-1659908.pdf

Comments

Post a Comment

Popular posts from this blog

Getter Template with Optional<> for IntelliJ IDEA

Image
If you are working with Java 8 and Intellij IDEA, good practice to use Optional for getters, of course depending of your logic :) I'll show how to quick configure IDE for generation such getters. Create new template and place this code: #if($field.modifierStatic) static ## #end Optional<$field.type> ## #set($name = $StringUtil.capitalizeWithJavaBeanConvention( $StringUtil.sanitizeJavaIdentifier($helper.getPropertyName($field, $project)))) #if ($field.boolean && $field.primitive) is## #else get## #end ${name}() { return Optional.ofNullable($field.name); }
Read more

JVM Memory and Tuning

Java Heap and Perm Space Java Heap space is used by java runtime to allocate memory to Objects and JRE classes. Java memory is separated into two different regions. These regions are called Heap space and Permgen (for Permanent Generation) For the HotSpot Java VM, the memory pools for serial garbage collection are the following. Eden Space (heap): The pool from which memory is initially allocated for most objects. Survivor Space (heap): The pool containing objects that have survived the garbage collection of the Eden space. Tenured Generation (heap): The pool containing objects that have existed for some time in the survivor space. Code Cache (non-heap): The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code. Permanent generation has been completely removed in JDK 8.  JDK8: Metaspace In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace. There are some ne
Read more

Three-phase commit protocol - 3PC

Image
Three-phase commit protocol (3PC) is a  distributed algorithm  which lets all nodes in a  distributed system  agree to  commit  a  transaction . Unlike the  two-phase commit protocol  (2PC) however, 3PC is non-blocking. Specifically, 3PC places an upper bound on the amount of time required before a transaction either commits or  aborts . This property ensures that if a given transaction is attempting to commit via 3PC and holds resource locks , it will release the locks after the timeout.  Three-Phase Commit protocol   - a non-blocking protocol Links: http://courses.cs.vt.edu/~cs5204/fall00/distributedDBMS/sreenu/3pc.html https://en.wikipedia.org/wiki/Three-phase_commit_protocol http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/
Read more