Syllabus:

UNIT V: Transaction Concept: Transaction State, ACID properties, Concurrent

Executions, Serializability, Recoverability, Implementation of Isolation, Testing for
Serializability, lock based, time stamp based, optimistic, concurrency protocols, Deadlocks,
Failure Classification, Storage, Recovery and Atomicity, Recovery algorithm.

Transaction:
A transaction in a DBMS refers to a series of operations that are executed together as a
single unit to perform a task, such as transferring money between accounts in a banking
system.
Transaction States in DBMS
These are the different types of Transaction States:
1. Active State
2. Partially Committed State
3. Failed State
4. Aborted State
5. Committed State
6. Terminated State
 State Description Example

BEGIN TRANSACTION;
Transaction is UPDATE accounts SET
Active
executing operations. balance = balance - 100
WHERE user_id = 1;

All operations are

After the last statement
Partially executed, but
executes but
Committed changes are not yet
before COMMIT.
saved permanently.

Changes are COMMIT; → Now, the

Committed permanently saved to balance update is
the database. permanent.

Transaction cannot UPDATE accounts SET

proceed (due to balance = balance - 1000
Failed
errors, constraints, WHERE user_id = 1; (Fails if
etc.). balance < 1000)

Transaction is rolled
ROLLBACK; → Reverts all
back, and the
Aborted changes made in the
database is restored
transaction.
to its previous state.

Transaction is either
Terminated committed or aborted
and no longer active.

ACID Properties:
1. Atomicity
Ensures all operations in a transaction complete successfully, or none do.
• Example: Transferring $100 between bank accounts. If either the withdrawal or
deposit fails, the entire transaction is rolled back
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1; -- Debit
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2; -- Credit
COMMIT;
 • If the credit fails, the debit is rolled back (no partial updates).
(2) Consistency
• Definition: A transaction brings the database from one valid state to another
(enforcing rules like constraints, triggers, etc.).
• Example:
o If an accounts table has a constraint balance >= 0, any transaction that
makes balance negative will be aborted.
3. Isolation
Prevents concurrent transactions from interfering.
• Example: Two users attempting to buy the last item in stock. Isolation ensures only
one transaction succeeds, updating inventory correctly

4. Durability
• Definition: Once a transaction is committed, its changes persist even after a system
crash.
• Example:
o After COMMIT, even if the database crashes, the balance updates remain
intact when the system recovers.

Concurrent Executions

Concurrent execution means multiple transactions are executed at the same time
(i.e., interleaved), rather than one after the other.
Why we need it:
• Improves performance (utilizes CPU & disk better)
• Increases throughput (multiple users can work simultaneously)

• Reduced average response time

•

Example:
Let’s consider two transactions T1 and T2 on a bank account having a balance of
₹5000.
• T1: Withdraw ₹1000
• T2: Deposit ₹2000
 Serial Execution (one after another):

T1: Read(balance = 5000)

balance = balance - 1000 = 4000
Write(balance = 4000)

T2: Read(balance = 4000)

balance = balance + 2000 = 6000
Write(balance = 6000)

Concurrent Execution (interleaved):

T1: Read(balance = 5000)
T2: Read(balance = 5000)
T1: balance = balance - 1000 = 4000
T1: Write(balance = 4000)
T2: balance = balance + 2000 = 7000 ← Incorrect!
T2: Write(balance = 7000)
Problem: Final balance should be ₹6000, but due to interleaving, it became ₹7000. This is a
lost update problem.

Serializability
Serializability ensures that even though transactions are executed concurrently, the final
result is equivalent to some serial execution of those transactions.
Types of Serializability:
1. Conflict Serializability: Based on non-conflicting operations (read/write
rules).
Two operations conflict if:
▪ They belong to different transactions
▪ They operate on the same data item
▪ At least one of them is a write operation
2. View Serializability: Based on read-from relationships.
 Example:
Let’s say we have two transactions again:
• T1: Read(A), Write(A)
• T2: Read(A), Write(A)

Schedule (order of operations):

T1: Read(A)
T2: Read(A)
T1: Write(A)
T2: Write(A)
This is not serializable, because the final result is not the same as any serial execution (T1
then T2 or T2 then T1).
But this one is serializable:
T1: Read(A)
T1: Write(A)
T2: Read(A)
T2: Write(A)
It is equivalent to T1 followed by T2.
Goal: Allow concurrency without violating correctness.

Recoverability
Definition:
A schedule is recoverable if a transaction that reads data written by another transaction
commits only after the writer transaction commits.
Why important?
To prevent using dirty (uncommitted) data which may be rolled back later.
Example:
Let’s say:
• T1: Write(A)
• T2: Read(A), Commit
• T1: Rollback
This is non-recoverable, because T2 used data written by T1, but T1 rolled back. So now T2
is using invalid data.
Types:
1. Recoverable Schedule: Transactions commit only after all transactions they read
from have committed
2. Cascadeless Schedule: Transactions can only read committed data (stronger than
recoverable)

Recoverable schedule:
• T1: Write(A)
• T2: Read(A)
• T1: Commit
• T2: Commit
Now it's safe, because T2 reads only committed data.

Example of Non-Recoverable Schedule:

T1: Read(A)
T1: A = A + 100
T1: Write(A)
T2: Read(A) // T2 reads uncommitted data from T1
T1: Rollback // Now T2 has read data that doesn't exist
Example of Recoverable Schedule:
T1: Read(A)
T1: A = A + 100
T1: Write(A)
T2: Read(A) // T2 reads uncommitted data from T1
T1: Commit // T1 commits first
T2: Commit // Then T2 commits - this is recoverable
Example of Cascadeless Schedule:
T1: Read(A)
T1: A = A + 100
T1: Write(A)
T1: Commit
T2: Read(A) // Only reads committed data
T2: Commit
These concepts are fundamental to maintaining database consistency while allowing
concurrent access to data.

Deadlocks in DBMS

A deadlock occurs when two or more transactions are waiting for each other to release
locks on resources, and none of them can proceed.
Example:
• T1 locks Resource A and waits for Resource B.
• T2 locks Resource B and waits for Resource A.
Now both are waiting indefinitely.

Conditions for Deadlock:

• Mutual exclusion
• Hold and wait
• No preemption
• Circular wait

1. Mutual Exclusion:
A resource can only be used by one process at a time. If another process requests that
resource, it must wait until the resource is released.
• Example:
If a printer is in use by Process A, Process B must wait for Process A to finish using the
printer before it can print.
2. Hold and Wait:
A process is holding at least one resource and is waiting to acquire another resource that is
currently held by another process.
• Example:
Process P1 is holding resource R1 and is waiting for resource R2, which is being held by
Process P2.

3. No Preemption:
Resources cannot be taken away from a process by force. A process must release resources
voluntarily when it's finished using them.
• Example:
If Process A is holding resource R1, the operating system cannot take R1 away from Process
A to give it to Process B.

4. Circular Wait:
A circular chain of processes exists where each process is waiting for a resource held by the
next process in the chain.
• Example:
Process A is waiting for R1 held by B, B is waiting for R2 held by C, and C is waiting for R3
held by A.

Deadlock Handling Strategies:

• Detection and Recovery: The system allows deadlocks to occur but has mechanisms
to detect and resolve them, typically by aborting one or more transactions to break
the cycle.
• Prevention: The system proactively ensures that deadlocks do not occur by imposing
certain constraints, such as ordering resource requests or using timeouts.
Deadlock Prevention: Two Main Approaches
Approach 1: Prevent Cyclic Waits (Resource Ordering)

1. All Locks at Once (Static Locking):

o A transaction must lock all its required data items before
execution.
o Either all locks are acquired in one step, or none are.
o Disadvantages:
1. Hard to predict all required data items in advance.
2. Low data utilization – data items may be locked but unused
for long periods.
2. Ordering of Data Items (Lock Ordering):
• All data items are assigned a total or partial order.
• Transactions must request locks in a sequence consistent with this
order.
• Example: Once a transaction locks item X, it cannot request locks on any
item before X in the order.
Approach 2: Preemption & Rollbacks (Timestamp-Based Techniques)
• When a potential deadlock is detected, instead of waiting, a transaction
may be rolled back (preempted).
• Each transaction gets a unique timestamp used for decision making (not
for locking itself).
• If a transaction is rolled back, it retains the same timestamp on restart.

Deadlock Detection Using Wait-For Graph (WFG)

Wait-For Graph (WFG):
• Definition: A directed graph G = (V, E) where:
o V: Set of vertices = all transactions in the system.
o E: Set of directed edges; an edge Ti → Tj exists if Ti is waiting for Tj to
release a data item.
Operations on the WFG:

• Add edge Ti → Tj: When Ti requests a lock held by Tj.

• Remove edge Ti → Tj: When Tj releases the data item and Ti is no longer waiting.

Deadlock Condition
• A deadlock exists if and only if the wait-for graph contains a cycle.
• All transactions in the cycle are deadlocked.

Example Scenario (from the book):

• Initial state (no cycle):

o T25 → T26, T25 → T27

o T27 → T26
o T26 → T28
→ No cycle → No deadlock
• Now, if T28 → T27 is added → Cycle:
o T26 → T28 → T27 → T26
→ Deadlock among T26, T27, T28.

Recovery from Deadlock

Selection of a victim. Given a set of deadlocked transactions, we must determine which
transaction (or transactions) to roll back to break the deadlock.
Rollback:We should roll back those transactions that will incur the minimum cost.
Once we have decided that a particular transaction must be rolled back, we must determine
how far this transaction should be rolled back. Partial rollback or total rollback
Starvation.
In a system where the selection of victims is based primarily on cost factors, it may happen
that the same transaction is always picked as a victim. As a result, this transaction never
completes its designated task, thus there is starvation.