Transaction

A transaction is a single logical unit of work formed by a set of

operations. the operations which are between the beginning and the
end of the transaction are counted as a single logical unit. The
database is inconsistent during the transaction. It goes into a
consistent state only when the transaction has occurred successfully.
It is very important to have a successful transaction.

For example , if you are sending $100 from your account to your
friend's account, then the money deducted from your account should
be reflected to your friend's account.

States Of Transaction
A transaction goes through any different states throughout its
lifecycle. These states also known as transaction state are as
follows:

1. Active State: This is the first state of the transaction and any
transaction which is being executed is in this state. The changes
made are stored in the buffer in the main memory.
2. Partially Committed: After the last operation is executed the
transaction enters into the partially committed state. This is
said partially committed because the changes made are still in
the buffer in the main memory.
3. Failed State: A transaction enters into the failed state if some
checks fail in the active state, some error occurs in the active or
partially committed state and the transaction cannot be
executed further.
4. Aborted State: If any transaction has reached the failed state
then the recovery manager rollback the database to its original
state from where the execution had started.
 5. Committed State: A transaction from the partially committed
state enters into the committed state if all the operations are
executed successfully. It is not possible to rollback from this
state and it is a new consistent state.

ACID Properties
For maintaining the integrity of data in the database the certain
properties are followed by all the transactions that take place in the
database. These properties are popularly known as ACID properties
where A is for Atomicity, C for Consistency, I for Isolation
and D for Durability.

Atomicity
This property states that the transaction should either occur
completely or doesn't occur at all. The transaction should not occur
partially. Each transaction is treated as a unit and the execution is
completed else the transaction is aborted. If any transaction is
aborted all the changes made are reversed back. If the transaction
occurs completely then only it is committed.

Example: Suppose there are two accounts A and B having a balance

of Rs 1000 and Rs 500 respectively. Now, if you have to transfer Rs
200 from Account A to Account B then this transaction involves two
operations . First, debiting Rs 200 from Account A and
second, crediting Rs 200 to Account B.

Now, let's consider a situation where the first operation has occurred
successfully i.e. Rs 200 was debited from Account A and the balance
in Account A is now Rs 800. But, the second transaction failed .
So, the Rs 200 was not added to Account B. This can lead to
inconsistency in the database. So, either the transaction should fail or
both the operations should occur if the transaction has to be
successful. The atomicity thus helps in ensuring the correctness of the
database.

Consistency
This property ensures that the integrity of the database is maintained
before and after the transaction. It ensures that when any transaction
is executed then the database should move from one consistent state
to another consistent state.

Example: In the above example, Account A and Account B have Rs

1000 and Rs 500 respectively. So, the total amount is Rs 1000+ Rs
500 i.e. Rs 1500 before the transaction. When any transaction is
executed then the total amount should also be Rs 1500. If the
transaction occurs then Rs 200 will be deducted from Account A and
added to Account B. So, the total amount after the transaction will Rs
800 + Rs 700 i.e. Rs 1500 . So, this property ensures the
consistency of the database. If any operation in the transaction fails it
will produce inconsistency in the data.

Isolation
This property tells that each transaction is executed in the system
such that it is the only transaction in the system. If more than one
transaction is taking place in parallel, then the occurrence of one
transaction will not affect the other transaction. If any transaction is
using a data item then it can’t be used by other transactions until the
first transaction ends.

Example: Suppose we have two transaction T1 and T2 which is

defined as follows.

Transaction 1: T1
BEGIN
Read(X)
X=X+50
Write(X)
Read(Y)
Y=Y-10
Write(Y)
END
Transaction 2: T2
BEGIN
Read(X)
Read(Y)
Z=X*Y
Write(Z)
END
Let X = 40, Y = 20.

Now, consider a situation where T1 has been executed until Read(Y)

and then T2 starts. Due to this, the transaction T2 reads
the incorrect value of Y . It reads the value as 20 and the
operations which it should have been performed by taking the value
as 10, T2 will perform by taking the value as 20. This leads to
inconsistent results. The output of the transaction T2 should have
been X*Y i.e. 90*10(=900) but it will produce the output
as 90*20 i.e. 1800 as T2 has read the incorrect value of Y. This
problem happened because of the transaction result of T1 was made
available for T2. So to avoid any such problem the transactions take
place in isolation.

Durability
This property ensures that once the changes are made in the database
these changes persist in the database even if any system failure
occurs. These changes are saved permanently in the non-volatile
memory. It is the responsibility of the recovery manager to ensure the
durability in the database.