Transaction in DBMS

A transaction can be defined as a group of tasks. A single task is the minimum processing unit which
cannot be divided further.
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)

ACID Properties
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.
1. Atomicity-
• This property ensures that either the transaction occurs completely or it does not occur at all.
• In other words, it ensures that no transaction occurs partially.
• That is why, it is also referred to as “All or nothing rule”.
• It is the responsibility of Transaction Control Manager to ensure atomicity of the transactions.
2. Consistency-
• This property ensures that integrity constraints are maintained.
• In other words, it ensures that the database remains consistent before and after the transaction.
• It is the responsibility of DBMS and application programmer to ensure consistency of the
database.
3. Isolation-
• This property ensures that multiple transactions can occur simultaneously without causing any
inconsistency.
• During execution, each transaction feels as if it is getting executed alone in the system.
• A transaction does not realize that there are other transactions as well getting executed parallely.
• Changes made by a transaction becomes visible to other transactions only after they are written
in the memory.
• The resultant state of the system after executing all the transactions is same as the state that
would be achieved if the transactions were executed serially one after the other.
• It is the responsibility of concurrency control manager to ensure isolation for all the
transactions.
4. Durability-
• This property ensures that all the changes made by a transaction after its successful execution
are written successfully to the disk.
• It also ensures that these changes exist permanently and are never lost even if there occurs a
failure of any kind.
• It is the responsibility of recovery manager to ensure durability in the database.
Transaction States-
A transaction goes through many different states throughout its life cycle.
These states are called as transaction states.
Transaction states are as follows-
1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Aborted state
6. Terminated state
 1. Active State-
• This is the first state in the life cycle of a transaction.
• A transaction is called in an active state as long as its instructions are getting executed.
• All the changes made by the transaction now are stored in the buffer in main memory.
2. Partially Committed State-
• After the last instruction of transaction has executed, it enters into a partially committed state.
• After entering this state, the transaction is considered to be partially committed.
• It is not considered fully committed because all the changes made by the transaction are still
stored in the buffer in main memory.
3. Committed State-
• After all the changes made by the transaction have been successfully stored into the database,
it enters into a committed state.
• Now, the transaction is considered to be fully committed.
4. Failed State-
• When a transaction is getting executed in the active state or partially committed state and some
failure occurs due to which it becomes impossible to continue the execution, it enters into
a failed state.
5. Aborted State-
• After the transaction has failed and entered into a failed state, all the changes made by it have
to be undone.
• To undo the changes made by the transaction, it becomes necessary to roll back the transaction.
• After the transaction has rolled back completely, it enters into an aborted state.
6. Terminated State-
• This is the last state in the life cycle of a transaction.
• After entering the committed state or aborted state, the transaction finally enters into
a terminated state where its life cycle finally comes to an end.
Concurrency Problems in DBMS-
• When multiple transactions execute concurrently in an uncontrolled or unrestricted manner,
then it might lead to several problems.
• Such problems are called as concurrency problems.
The concurrency problems are-
1. Dirty Read Problem
2. Unrepeatable Read Problem
3. Lost Update Problem
4. Phantom Read Problem
1. Dirty Read Problem-
This read is called as dirty read because-
• There is always a chance that the uncommitted transaction might roll back later.
• Thus, uncommitted transaction might make other transactions read a value that does not even
exist.
• This leads to inconsistency of the database.
Example-

Here,
1. T1 reads the value of A.
2. T1 updates the value of A in the buffer.
3. T2 reads the value of A from the buffer.
4. T2 writes the updated the value of A.
5. T2 commits.
6. T1 fails in later stages and rolls back.
In this example,
• T2 reads the dirty value of A written by the uncommitted transaction T1.
• T1 fails in later stages and roll backs.
• Thus, the value that T2 read now stands to be incorrect.
• Therefore, database becomes inconsistent.
2. Unrepeatable Read Problem-
This problem occurs when a transaction gets to read unrepeated i.e. different values of the same variable
in its different read operations even when it has not updated its value.
Example-
Here,
1. T1 reads the value of X (= 10 say).
2. T2 reads the value of X (= 10).
3. T1 updates the value of X (from 10 to 15 say) in the buffer.
4. T2 again reads the value of X (but = 15).
In this example,
• T2 gets to read a different value of X in its second reading.
• T2 wonders how the value of X got changed because according to it, it is running in isolation.
3. Lost Update Problem-
This problem occurs when multiple transactions execute concurrently and updates from one or more
transactions get lost.
Example-

Here,
1. T1 reads the value of A (= 10 say).
2. T2 updates the value to A (= 15 say) in the buffer.
3. T2 does blind write A = 25 (write without read) in the buffer.
4. T2 commits.
5. When T1 commits, it writes A = 25 in the database.
In this example,
 • T1 writes the over written value of X in the database.
• Thus, update from T1 gets lost.
4. Phantom Read Problem-
This problem occurs when a transaction reads some variable from the buffer and when it reads the same
variable later, it finds that the variable does not exist.
Example-

Here,
1. T1 reads X.
2. T2 reads X.
3. T1 deletes X.
4. T2 tries reading X but does not find it.
In this example,
• T2 finds that there does not exist any variable X when it tries reading X again.
• T2 wonders who deleted the variable X because according to it, it is running in isolation.
Avoiding Concurrency Problems-
• To ensure consistency of the database, it is very important to prevent the occurrence of above
problems.
• Concurrency Control Protocols help to prevent the occurrence of above problems and
maintain the consistency of the database.