Demystifying ACID Properties of a Database Transaction to a 10-year-old
A Kid’s Perspective
Hey Lad, just kidding :) of course, you are not a kid, or are you? Mhhmm.
The purpose of this article is to explain the ACID properties of a database transaction in the clearest and most concise manner possible.
What is a transaction?
Databases and data storage systems are always being interacted with at almost every point of an application lifecycle. A transaction, in this context, is any database operation or sequence of operations that are treated as a single unit of work, which either completes fully or does not complete at all, and leaves the storage system in a consistent state.
A classic example would be to consider two kids, Ken, who owns a considerable amount of chocolate bars in his pockets, and Bob, who has a collection of Pokémon toys in his toy box, trying to exchange chocolate bars with toys. Either Bob has given Ken a Pokémon toy for a few chocolate bars, or has not — there can not be an in-between state.
ACID is an acronym for a set of 4 key properties that define a transaction: Atomicity, Consistency, Isolation, and Durability. If any operation performed on a storage system(database) has these ACID properties, it can be called an ACID transaction, and the data storage systems that apply these operations are called transactional systems.
Why should we implement ACID Transactions?
ACID transactions ensure the highest possible data reliability and integrity. They ensure that your data never falls into an inconsistent state because of an operation that only partially completes. For example, without ACID transactions, if Ken gives Bob 5 chocolate bars for a single Pokémon toy, but Bob is called into the house by his mum unexpectedly, this results in an awkward situation between the boys, because Bob now has the chocolate bars but Ken does not have the Pokémon toy return, Bob could not retrieve the Pokémon toy on time from his box and give to Ken before he was called in by his mum. Similarly, if you were writing some data to a database table, but the power went out unexpectedly, it’s possible that only some of your data would have been saved, while some of it would not. Now your database is in an inconsistent state that is very difficult and time-consuming to recover from.
Atomicity
From our usual example, let’s say Ken has 10 chocolate bars, and really wants a Pokémon toy which Bob has a collection of. So the boys make a deal: Ken gives Bob just 5 chocolate bars, and in return, Bob will give Ken the toy.
Now, let’s talk about transaction atomicity. Atomicity means that the transaction happens as a whole, without being divided or interrupted. In simpler terms, it means that either the whole transaction is completed successfully, or nothing happens at all.
In our example, atomicity means that both parts of the transaction (the exchange of chocolate bars and the toy) must happen completely, or none of it will happen. So, let’s see how atomicity plays out in this situation:
- Ken and Bob agree to the deal.
- They both gather the chocolate bars and the toy, preparing for the exchange.
- At this point, something unexpected happens. Bob’s mum comes and takes away the Pokémon toy, saying that Bob can’t trade them.
- Since atomicity is important, the whole transaction is canceled. Neither Ken nor Bob get what they wanted. Ken still has his chocolate bars, and Bob still has their toy.
Atomicity ensures that if any part of the transaction fails or is interrupted, everything goes back to how it was before the transaction started. In this case, because Ken couldn’t give away the chocolate bars, Bob doesn’t have to give Ken the toy either.
So, in summary, atomicity means that the transaction happens as a whole, and if any part of it fails, everything is rolled back, and nothing changes.
Consistency
Not going out of the already established context, we say Ken has 10 chocolate bars and Bob has a collection of Pokémon toys, say about 5 of them. And yes of course the deal is for Ken to give Bob 5 chocolate bars to get one Pokémon toy from Bob. Consistency ensures that any interruption of exchange between the two boys doesn’t lead to unintended consequences.
Now, let’s discuss consistency in this scenario:
- Initially, Ken has 10 chocolate bars, and Bob has the toy.
- They agree on the deal and proceed to exchange the items.
- Ken gives 5 chocolate bars to Bob, and Bob hands over the toy to Ken.
- At this point, consistency ensures that both sides of the trade are completed successfully and in a consistent manner.
- If Ken doesn’t give 5 chocolate bars to Bob, consistency would be violated. Bob would not receive the agreed-upon number of chocolate bars, and the deal would be inconsistent.
- Similarly, if Bob doesn’t give the toy to Ken after receiving 5 chocolate bars, consistency would be compromised. Ken would not get the toy he expected, and the trade would be inconsistent.
Consistency ensures that at any point in the exchange, the total value of the items is the same and correct. Before the exchange, we have 10 chocolates and 5 toys which equates to 15 items, after the exchange, Bob is 1 toy less but has now gained 5 chocolate bars and Ken is 5 chocolate bars less but has also gained 1 toy. The sum total of the items with each of the boys, Ken, 5 chocolate bars with 1 toy, making 6 items, and Bob with 4 toys and 5 chocolate bars, 9 items, would be 15, which is the same as the original total before exchange.
Consistency ensures that both sides of the transaction are fulfilled correctly and that the agreed-upon terms are met. It prevents any partial or incomplete exchanges, ensuring that both Ken and Bob end up with the items they anticipated.
Isolation
Isolation is the property that allows concurrency control, so updates or modifications from one transaction are not affecting operations in another transaction. It ensures that a transaction in process, or that is not yet committed is isolated from any other transaction. Each transaction maintains its independence and integrity.
Let’s explore isolation using the example of children exchanging chocolate bars for a toy:
- Ken and Bob agree to the trade: Ken will give Bob 5 chocolate bars, and Bob will give Ken the toy.
- However, there is also another child, Charlie, Charlie wants to trade with Bob. Charlie has 3 candy bars and wants to exchange them for one of Bob’s Pokémon toys.
- Both transactions start simultaneously:
- Ken begins by giving his 5 chocolate bars to Bob.
- Charlie starts by giving his 3 candy bars to Bob.
- Isolation ensures that each transaction operates independently and does not interfere with the other. Here’s how it works in this scenario:
If isolation is not maintained, interference between the transactions can occur. For example:
- If Bob has a single Pokémon toy to offer and the exchanges do not happen in isolation, there might be a conflict because both Ken and Charlie would offer something leaving Bob in confusion about who to choose or Bob would simply be in debt if he has collected from both Ken and Charlie and can only give to one of them. This would also lead to inconsistency in the system.
However, with isolation properly enforced:
- Ken completes his transaction first, giving all 5 chocolate bars to Bob. The system ensures that Ken’s transaction is isolated and does not interfere with other transactions.
- After Ken’s transaction is committed, Bob now has 5 chocolate bars.
- Charlie’s transaction proceeds independently. He gives his 3 candy bars to Bob, completing his trade for the toy.
- The system ensures that Charlie’s transaction is isolated and does not interfere with Ken’s completed transaction.
- In a case where Bob has just one single toy, he can tell Charlie that the toy is no longer in his possession.
Isolation ensures that concurrent transactions are isolated from one another, preventing interference, inconsistency, or conflicts. It allows transactions to operate as if they are executing sequentially, even when multiple transactions are happening simultaneously.
By maintaining isolation, the database system guarantees that each transaction’s results are consistent and independent, contributing to data integrity and reliability.
Durability
The very last of the ACID properties, Durability. In the light of when a transaction successfully completes, changes to data persist and are not undone, even in the event of a system failure. This guarantees that even in the face of system failures or crashes, once successful transactions are acknowledged and written to the database, they can never be reversed or lost.
Let’s see how durability applies to our example of children exchanging chocolate bars for a toy:
- Ken and Bob agree to the trade: Ken will give Bob all 5 chocolate bars, and Bob will give Ken the toy.
- They proceed with the exchange:
- Ken gives all 5 chocolate bars to Bob.
- Bob hands over the toy to Ken.
- The children go to show their mothers.
At this point, durability comes into play:
- For example, if Ken realizes that the toy he got from Bob is faulty or is scolded by his mum for doing such, the exchange can not be reversed because Bob’s mother had acknowledged the exchange and noted that Bob now has one less Pokémon toy in his collection. Also, the chocolate bars he gave Bob are no longer in Bob’s possession, but rather somewhere along his digestion process, lol. Durability guarantees that the data remains intact and the trade is preserved.
Durability is typically achieved through techniques such as logging, journaling, or transaction logging. These techniques ensure that changes made during a transaction are recorded in a persistent manner before they are considered committed. If a failure occurs, the system can use the recorded information to recover the database to a consistent state and apply the changes once the system is back up.
In our example, durability ensures that even if a power outage or system crash happens right after the trade, the system can recover and restore the state of the database to where Ken has given all 5 chocolate bars to Bob, and Bob has given the toy to Ken.
In summary, durability guarantees that once a transaction is committed, its changes are permanent and will survive any failures or crashes. It ensures the reliability and persistence of data, providing assurance that transactions and their effects are durable and will not be lost due to unforeseen events.
How are ACID transactions implemented?
The most common implementation of ACID transactions is done via save points, rollbacks, and locks. Data is locked (not accessible by another transaction) until a transaction completes or fails, to guarantee atomicity, isolation, and consistency.
Conclusion
The ACID properties of a transaction are important in achieving solid data reliability, consistency, and integrity in our applications. However, it has its shortcomings and alternatives also. You can read more about this and ACID properties from the link below:
Hopefully, this was an interesting read for you :)
