Prelude
A centralized relational database tries to show a robust data consistency and concurrency control.
But in a world where chasing to improve performance is a constant, so when we are dealing with databases clusters, issues like update consistency, reading consistency,replicatation consistency, eventual consistency,conditional update, etc comes to hand.
Let's talk about the many ways that consitency may mean.
The issue with "Update consistency"
In this situation we have to deal with write-write conflict, means two clients trying to update the same data at the same time.
When there is a centralized database, a single node, that receive all writes, then we are trying to maintain consistency confronting concurrency.
Scenery like this are described as optimistic and pessimistic.
Keeping consistency in a optimistic way
In optimistic scenario, the node accepts all writes, and after try to solve the conflicts.
An approach very common is the "conditional update", means, test the data before write.
Let's say, along with the data that will be updated, a field called "version" is used to test the update. Every update that occurs the version number is incremented.
In a context that conflicts happen rarely, this approach works fine.
In other hand, in a context that conflicts happen many times, many data can be without updates and will be lost.
Keeping consistency in a pessimistic way
The premise here is "no conflict will happen".
No write will happen until the current write finishes its update.
By the strategy nature, performance is not a priority here.
This strategy, many times, leads to deadlocks conflicts.
By the end, when we are building a software, there is not the right answer, the answer is depends what the business need.
What characteristics your software must have?
Security and responsiveness are fundamental when dealing with concurrent programming.
Top comments (0)