ACID properties are crucial in ensuring that databases remain reliable and consistent, even in the face of system failures or crashes during transactions. These properties Atomicity, Consistency, Isolation, and Durability help maintain data integrity in environments like banking systems, e-commerce applications, and online transactions.
In this article, we’ll dive into each ACID property and explore their importance, real-life examples, and use cases.
What Are ACID Properties?
1. Atomicity
The term atomicity comes from the concept of an atom, which is the smallest indivisible unit of matter. In the context of databases, atomicity refers to transactions being indivisible—either they fully succeed or fully fail.
If a transaction involves multiple steps, all of them must be completed successfully for the transaction to be considered successful. If any part of the transaction fails, the entire transaction is rolled back to maintain data integrity. This ensures that data is never left in an inconsistent or incomplete state.
Real-Life Example: Switch Flipping
Imagine flipping a light switch in your house. The light can either be fully ON or OFF, but there’s no state in between. If the switch fails halfway, the light doesn’t flicker or partially turn on—it remains in its original state.
Similarly, in a database transaction, if one part fails, the entire transaction fails, reverting any changes made.
Bank Transfer Example:
- User A, Account Balance: $100
- User B, Account Balance: $50
If User A initiates a transfer of $50 to User B, and an error occurs during the transaction, atomicity ensures that no changes are made to the database—both users’ balances remain unchanged. Abort will trigger.
— Abort : If a transaction aborts, changes made to the database are not visible.
If the transfer is successful, both User A and User B’s balances are updated, and the transaction is committed to the database. Commit will trigger.
— Commit : If a transaction commits, changes made are visible.
2. Consistency
Consistency ensures that the database remains in a valid state before and after the transaction. It guarantees that the database adheres to all defined rules, such as constraints, triggers, and relationships, sufficient balance after the transaction completes.
Real-Life Example: Balance Validation
- User A, Account Balance: $100
- User B, Account Balance: $50
If User A tries to transfer $200 to User B, the consistency property ensures that the transaction fails because User A does not have sufficient funds. The database will not allow the transaction to complete if it violates any defined rules, such as ensuring account balances do not go negative.
3. Isolation
Isolation ensures that transactions are processed independently, even if they occur simultaneously. This means that the operations in one transaction are isolated from others and are not affected by concurrent transactions, preventing inconsistencies.
Locking Mechanisms: Shared and Exclusive Locks
To maintain isolation, databases use locking mechanisms. Locks are applied to data to prevent other transactions from accessing or modifying it while the current transaction is in progress. There are two primary types of locks:
- Shared Lock (S-lock): Allows a transaction to read the data but not modify it. Other transactions can also acquire a shared lock on the same data, allowing multiple transactions to read the data simultaneously but preventing modifications.
Exclusive Lock (X-lock): Prevents other transactions from reading or modifying the data. This is applied when a transaction needs to update data to ensure that no other transaction interferes with the process.
Real-Life Example: Bank Transfer with Concurrent Transactions
Let’s consider two transactions happening simultaneously:Transaction 1: User A is transferring $100 from Account A to Account B.
Transaction 2: User B is transferring $50 from Account B to Account C.
Without isolation, these transactions could interfere with each other, leading to inconsistent balances.
How Isolation Works:
When Transaction 1 starts, it reads Account A’s balance (say, $500). At the same time, Transaction 2 reads Account B’s balance (say, $200). If there’s no isolation, Transaction 1 might update Account A’s balance to $400, while Transaction 2 could simultaneously update Account B’s balance to $150, leading to incorrect balances.
With isolation, these two transactions operate independently, so:
- Transaction 1 locks Account A (using an exclusive lock) to prevent any other transaction from modifying it until the transaction is complete.
- Transaction 2 waits until Transaction 1 commits, at which point it reads the updated balance of Account B and proceeds.
This prevents transactions from reading or modifying the same data simultaneously, avoiding inconsistencies.
Handling Concurrent Transactions with Locking:
- If both Transaction 1 and Transaction 2 try to access the same record at the same time, the database will use locking to ensure that only one transaction can proceed at a time, preventing data corruption.
- If both transactions attempt to lock the same resource, a deadlock may occur, where both transactions are waiting for each other to release the lock. The database can resolve deadlocks by rolling back one of the transactions, ensuring the system doesn’t hang.
4. Durability
Durability ensures that once a transaction has been committed, its changes are permanent. Even in the event of system crashes, power outages, or failures, the changes made by the transaction will not be lost.
Real-Life Example: Power Outage after Bank Transfer
Let’s say User A transfers $500 to User B. After the transaction is committed, the system crashes due to a power outage. However, because the transaction was committed, the changes to both User A’s and User B’s balances are written to durable storage (such as a disk). When the system restarts, the committed transaction is recovered, and both users’ balances are updated as expected.
Thank you for reading my article. Stay tuned for more in-depth articles 😊
Top comments (0)