When dealing with databases or talking about transactions, system design etc; the term ACID property is very commonly used. In the lite blog, we will learn about ACID property with a simple example. This is a very simple tutorial on ACID properties.
What is transaction and problems around it
A transaction in the DBMS context, is a logical, independent unit of work that is performed to access (read), create or modify (update/delete) information in a database management system. While transaction is the very basic, simple unit of work; it also brings in a lot of complexities in a system.
Running multiple transactions on same set of data, can introduce data inconsistency, lack of data accuracy. Data integrity itself can be compromised; completeness of data is not guaranteed either.
In order to get past these issues around transnational processing, to ensure the database consistency is maintained before and after transactions, ACID property was introduced. ACID is an acronym derived from Atomicity, Consistency, Isolation and Durability.
Let’s take deeper look into each of these properties –
- a rollback/abort command ensures that all changes by a transaction is discarded and previous stable state is restored. This is an example of transaction doing nothing.
- a successful commit command ensures that all the changes by the transaction is successful. Database table now represents a new stable state by successful execution of the transaction.
With the consistency property, a transaction ensures that DB is transformed from one stable/valid/consistent state to another. All the integrity constraints are maintained as part of transaction. This responsibility is mainly with the implementation of code by developer.
Example:- If we take the same example as above, consistency in this transaction will ascertain that the total value of funds in Account-1 and Account-2 remain same before and after transactions.
- Another transaction T-2 sees this X amount in either Account-1 or in Account-2 depending on when actually T-2 is seeing the account details.
- It will never happen that T-2 sees X amount in both the accounts.
- It will never happen that T-2 doesn’t see the X amount in both Account-1 or Account-2 at the same time; meaning that X amount is deducted from Account-1 but not credited to Account-2.
Once a transaction successfully completes, the changes are persisted in the disk and these changes cannot be undone even in case of system failure. In other words, these changes are permanent in nature.
Example:- If we take our example, A transaction successfully transferred amount X from Account-1 to Account-2. The durability property will ensure that the changes made to the accounts won’t be reversed/undone in any circumstance.