• A transaction is a set of related changes which is used to achieve some of the ACID properties. Transactions are tools to achieve the ACID properties.
• A transaction can be defined as a group of tasks. A single task is the minimum processing unit which cannot be divided further.
• A transaction in a database system must maintain Atomicity,Consistency, Isolation, and Durability − commonly known as ACID properties − in order to ensure accuracy, completeness, and data integrity.
• Let’s take an example of a simple transaction. Suppose a bank employee transfers Rs 500 from A's account to B's account.
• This very simple and small transaction involves several low-level tasks.

• A’s Account

  Open Account(A)
  Old.Balance=A.balance
  New.Balance=Old.Balance – 500
  A.balance= New.Balance
  Close.Account(A).
  

• B’s Account

  Open Account(B)
  Old.Balance=B.balance
  New.Balance=Old.Balance + 500
  B.balance= New.Balance
  Close.Account(B).
  

The ACID Properties of a Transaction are as follows:

i. Atomicity :

• This property states that a transaction must be treated as an atomic unit, that is, either all of its operations are executed or none.
• There must be no state in a database where a transaction is left partially completed.
• States should be defined either before the execution of the transaction or after the execution/abortion/failure of the transaction.
• When an update occurs to a database, either all or none of the update becomes available to anyone beyond the user or application performing the update.
• This update to the database is called a transaction and it either commits or aborts.
• This means that only a fragment of the update cannot be placed into the database, should a problem occur with either the hardware or the software involved.

ii. Consistency:

• Consistency is the ACID property that ensures that any changes to values in an instance are consistent with changes to other values in the same instance.
• The database must remain in a consistent state after any transaction.
• No transaction should have any adverse effect on the data residing in the database.
• If the database was in a consistent state before the execution of a transaction, it must remain consistent after the execution of the transaction as well.
• For example, we may have a table or a record on which two transaction are trying to read or write at the same time.
• Careful mechanisms are created in order to prevent mismanagement of these sharable resources, so that there should not be any change in the way a transaction performs.
• A transaction which deposits Rs 100/- to account A must deposit the same amount whether it is acting alone or in conjunction with another transaction that may be trying to deposit or withdraw some amount at the same time.

iii. Isolation :

• In a database system where more than one transaction are being executed simultaneously and in parallel, the property of isolation states that all the transactions will be carried out and executed as if it is the only transaction in the system.
• For example, user A withdraws $$100 and user B withdraws $250 from user Z’s account, which has a balance of $1000.
• Since both A and B draw from Z’s account, one of the users is required to wait until the other user transaction is completed, avoiding inconsistent data.
• Now, B can withdraw 250 from this $900 balance.

iv. Durability:

• The database should be durable enough to hold all its latest updates even if the system fails or restarts.
• If a transaction updates a chunk of data in a database and commits, then the database will hold the modified data.
• If a transaction commits but the system fails before the data could be written on to the disk, then that data will be updated once the system springs back into action.
• Features to consider for durability:
  • Recovery to the most recent successful commit after a database software failure.
  • Recovery to the most recent successful commit after an application software failure.
  • Recovery to the most recent successful commit after a CPU failure.
  • Recovery to the most recent successful backup after a disk failure.

Recovery to the most recent successful commit after a data disk failure