ACID Properties

There are four required properties that a transaction has to fulfill in order to maintain data integrity. These properties, also called ACID properties, are as follows:

• Atomicity A transaction has to be either completely done or completely undone. For example: While withdrawing money from an ATM, a customer's operation details, along with his card number and PIN are verified. The bank approves the transaction, performs the steps to process the transaction, and finally the ATM dispenses the money. Atomicity here means that either all of these steps have been fully completed or they have all been completely rolled back.

• Consistency A transaction must preserve its integrity constraints. That is to say, if there is a failure at any point, the data must be restored to the state it was in before the transaction began. This means that even if the data goes through any changes during the transaction, or in the case of a failure, the value of the data is restored to its last consistent value before the transaction started.

• Isolation Concurrent transactions must be handled independently. If there are multiple transactions running concurrently, they should be independent of each other. Any partly processed data (inconsistent data) from any transaction should not be exposed to another transaction. This is implemented by DBMS, using locking.

• Durability After a transaction is completed, the state should be persistent despite any failures that might occur at a later stage.

Now that we have seen what a transaction is and what its ACID properties are, let's look at the architecture of a transaction.