A transaction is a collection of instructions. To maintain the integrity of a database, all transactions must obey ACID properties. ACID is an acronym for
atomicity, consistency, isolation, and durability. Let’s go over each of these properties.
A transaction is an atomic unit; hence, all the instructions within a transaction will successfully execute, or none of them will execute. The following transaction transfers 20 dollars from Alice’s bank account to Bob’s bank account. If any of the instructions fail, the entire transaction should abort and rollback.
A database is initially in a consistent state, and it should remain consistent after every transaction. Suppose that the transaction in the previous example fails after Write(A_b) and the transaction is not rolled back; then, the database will be inconsistent as the sum of Alice and Bob’s money, after the transaction, will not be equal to the amount of money they had before the transaction.
Isolation property ensures concurrent transactions should not interfere with each other, and their results should be the same as if they were executed sequentially. Suppose, bob has two types of accounts and performs two different transactions (T1, T2) to both accounts concurrently, then these transactions should operate in isolation. Otherwise, the current balance might be incorrect as shown in the given illustration.
Changes that have been committed to the database should remain even in the case of software and system failure. For instance, if Bob’s account contains $120, this information should not disappear upon system or software failure.