When we work with databases, there can be multiple events that can go wrong. A few of them are:
- Several clients can update the same data, leading to overwriting each other’ changes
- Several client can read partially updated data that doesn’t make sense
- The database can go down and lead to partial updates of write.
- The application may crash and lead to partial updates of write.
- Network issues can cut off both databases and applications and lead to partial write updates.
Databases have to deal with all these faults and avoid catastrophic failures. The safety guarantees provided by the transactions are defined by ACID which stands for
A: Atomicity
C: Consistency
I: Isolation
D: Durability
Atomicity
If the writes are grouped together into an atomic transaction, and the transaction cannot be completed (committed) due to a fault, then the transaction is aborted and the database must discard or undo any writes it has made so far in that transaction.
For more understanding of atomicity refer to:
Clear your ACID concepts with me — Part 1
Consistency
I would like to discuss the I and D of ACID, before jumping into this. I will surely talk about consistency in my later posts.
Let’s start
Isolation
Let’s start it with a simple situation
You work in a social networking company and are given a feature to manage i.e., “like counts” of videos. You developed this feature by incrementing the counter and tested this feature individually and deployed it. As it is just a counter incrementation, it should work fine. What a big deal!?
But a bug is raised that users are not able to see correct like counts.
You checked everything it is just
counter = counter + 1;
How can this fail?
I will tell you, we missed the fact that multiple users are liking the video concurrently.
Consider two users simultaneously who liked the video. Each user read the liked count as 10 incremented it by 1 and updated DB with 11. The like count should be 12 but it is 11 because of race conditions.
How this can be solved at the DB layer?
Isolation in the database saves us from these situations
Isolation means that concurrently executing transactions are isolated from each other.
The database ensures that when the transactions have been committed, the result is the same as if they had run serially (one after another), even though in reality they may have run concurrently.
An isolation level protects against one or more types of race conditions and provides an abstraction that we can use to reason about concurrency. The stronger the isolation level is, the more protection it offers against race conditions, but the less performant it is.
Transactions can have different isolation levels that are defined based on the type of race conditions they forbid:
- Serializable
- Repeatable reads
- Read Committed
- Read uncommitted
I can talk about all of these levels and discuss them in as understandable a way it is possible. Let me know in the comments if you want me to :)
Durability
For more understanding of durability refer to:
Soon, I will be sharing the C and D of ACID.
Copyright © 2023 fintechcoddler.blogspot.com