UNIT 3

In the world of Database Management Systems (DBMS), transactions are fundamental

operations that allow us to modify and retrieve data. However, to ensure the integrity of a
database, it is important that these transactions are executed in a way that maintains
consistency, correctness, and reliability. This is where the ACID properties come into play.
ACID stands for Atomicity, Consistency, Isolation, and Durability. These four key
properties define how a transaction should be processed in a reliable and predictable manner,
ensuring that the database remains consistent, even in cases of failures or concurrent
accesses.
What Are Transactions in DBMS?
A transaction in DBMS refers to a sequence of operations performed as a single unit of
work. These operations may involve reading or writing data to the database. To maintain data
integrity, DBMS ensures that each transaction adheres to the ACID properties. Think of a
transaction like an ATM withdrawal. When we withdraw money from our account, the
transaction involves several steps:
 Checking your balance.
 Deducting the money from your account.
 Adding the money to the bank's record.
For the transaction to be successful, all steps must be completed. If any part of this process
fails (e.g., if there’s a system crash), the entire transaction should fail, and no data should be
altered. This ensures the database remains in a consistent state.
The Four ACID Properties
1. Atomicity: "All or Nothing"
Atomicity ensures that a transaction is atomic, it means that either the entire transaction
completes fully or doesn't execute at all. There is no in-between state i.e. transactions do not
occur partially. If a transaction has multiple operations, and one of them fails, the whole
transaction is rolled back, leaving the database unchanged. This avoids partial updates that
can lead to inconsistency.
 Commit: If the transaction is successful, the changes are permanently applied.
 Abort/Rollback: If the transaction fails, any changes made during the transaction are
discarded.
Example
If the transaction fails after completion of T1 but before completion of T2 , the database
would be left in an inconsistent state. With Atomicity, if any part of the transaction fails, the
entire process is rolled back to its original state, and no partial changes are made.
2. Consistency: Maintaining Valid Data States
Consistency ensures that a database remains in a valid state before and after a transaction. It
guarantees that any transaction will take the database from one consistent state to another,
maintaining the rules and constraints defined for the data. In simple terms, a transaction
should only take the database from one valid state to another. If a transaction violates any
database rules or constraints, it should be rejected, ensuring that only consistent data exists
after the transaction.
Example: Suppose the sum of all balances in a bank system should always be constant.
Before a transfer, the total balance is $700. After the transaction, the total balance should
remain $700. If the transaction fails in the middle (like updating one account but not the
other), the system should maintain its consistency by rolling back the transaction
Total before T occurs = 500 + 200 = 700 .
Total after T occurs = 400 + 300 = 700 .

3. Isolation: Ensuring Concurrent Transactions Don't Interfere

This property ensures that multiple transactions can occur concurrently without leading to
the inconsistency of the database state. Transactions occur independently without
interference. Changes occurring in a particular transaction will not be visible to any other
transaction until that particular change in that transaction is written to memory or has been
committed.
This property ensures that when multiple transactions run at the same time, the result will be
the same as if they were run one after another in a specific order. This property prevents
issues such as dirty reads (reading uncommitted data), non-repeatable reads (data
changing between two reads in a transaction), and phantom reads (new rows appearing in a
result set after the transaction starts).
4. Durability: Persisting Changes
This property ensures that once the transaction has completed execution, the updates and
modifications to the database are stored in and written to disk and they persist even if a
system failure occurs. These updates now become permanent and are stored in non-volatile
memory. In the event of a failure, the DBMS can recover the database to the state it was in
after the last committed transaction, ensuring that no data is lost.
Example: After successfully transferring money from Account A to Account B, the changes
are stored on disk. Even if there is a crash immediately after the commit, the transfer details
will still be intact when the system recovers, ensuring durability.

Advantages of ACID Properties in DBMS

1. Data Consistency: ACID properties ensure that the data remains consistent and
accurate after any transaction execution.
2. Data Integrity: It maintains the integrity of the data by ensuring that any changes to
the database are permanent and cannot be lost.
3. Concurrency Control: ACID properties help to manage multiple transactions
occurring concurrently by preventing interference between them.
4. Recovery: ACID properties ensure that in case of any failure or crash, the system can
recover the data up to the point of failure or crash.
Disadvantages of ACID Properties in DBMS
1. Performance Overhead: ACID properties can introduce performance costs,
especially when enforcing isolation between transactions or ensuring atomicity.
2. Complexity: Maintaining ACID properties in distributed systems (like microservices
or cloud environments) can be complex and may require sophisticated solutions like
distributed locking or transaction coordination.
3. Scalability Issues: ACID properties can pose scalability challenges, particularly in
systems with high transaction volumes, where traditional relational databases may
struggle under load.
ACID in the Real World: Where Is It Used?
In modern applications, ensuring the reliability and consistency of data is crucial. ACID
properties are fundamental in sectors like:
  Banking: Transactions involving money transfers, deposits, or withdrawals must
maintain strict consistency and durability to prevent errors and fraud.
 E-commerce: Ensuring that inventory counts, orders, and customer details are handled
correctly and consistently, even during high traffic, requires ACID compliance.
 Healthcare: Patient records, test results, and prescriptions must adhere to strict
consistency, integrity, and security standards.

Serializability and Concurrency Control –

 In a multi-user database system, multiple transactions may be executed
simultaneously. However, to ensure data consistency and integrity, these transactions
must be executed in such a way that the final outcome is the same as if the transactions
had been executed serially (one after the other). This is where serializability comes
into play.
 Serializability refers to the property that ensures that the execution of multiple
transactions concurrently produces a result that is equivalent to some serial execution
order. In other words, the database system must ensure that even when transactions are
run concurrently, the final outcome should be the same as if those transactions were
executed sequentially, one by one, without overlapping.
 Concurrency control is the mechanism used to manage the concurrent execution of
transactions, ensuring that they do not interfere with each other in ways that could
violate ACID properties (especially isolation). The goal of concurrency control is to
prevent conflicts like lost updates, dirty reads, and uncommitted data, and to
maintain the consistency of the database.

Key Concepts of Serializability and Concurrency Control

Serializability
 Definition: Ensures that the results of executing a set of transactions concurrently are
equivalent to executing them in some serial order (one after another).
 Types of Serializability:
1. Conflict Serializability: Ensures that the schedule (order of operations) can be
rearranged to produce a serial schedule by swapping operations that do not
conflict.
2. View Serializability: Ensures that transactions produce the same final result,
even if the operations are reordered.
Concurrency Control
 Definition: Techniques used to ensure that concurrent transactions execute in such a
way that the database’s integrity and consistency are maintained.
 Goals:
o Prevent dirty reads, lost updates, and uncommitted data.
o Ensure transactions maintain the ACID properties.
 Methods of Concurrency Control:
1. Locking:
 Shared Locks: Allow multiple transactions to read but not write.
 Exclusive Locks: Allow a transaction to read and write, blocking others.
2. Timestamp Ordering: Ensures that transactions are executed based on their
timestamps to prevent conflicts.
3. Optimistic Concurrency Control: Allows transactions to execute without restrictions
and checks for conflicts at the end before committing.
4. Two-Phase Locking (2PL): Transactions acquire locks and release them in two
phases — first, acquiring all locks, and second, releasing them. Ensures conflict
serializability.

Example
 Three transactions—t1, t2, and t3—are active on a schedule "S" at once. Let's
create a graph of precedence.
Transaction - 1 Transaction - 2 Transaction - 3
(t1) (t2) (t3)

R(a)

R(b)

R(b)

W(b)

W(a)

W(a)

R(a)

W(a)

 It is a conflict serializable schedule as well as a serial schedule because the

graph (a DAG) has no loops. We can also determine the order of transactions
because it is a serial schedule.
 DAG of transactions
 As there is no incoming edge on Transaction 1, Transaction 1 will be executed
first. T3 will run second because it only depends on T1. Due to its dependence
on both T1 and T3, t2 will finally be executed.
 Therefore, the serial schedule's equivalent order is: t1 --> t3 --> t2
Lock-Based Concurrency Control – Paragraph Explanation
In lock-based concurrency control, transactions are synchronized using locks to prevent
conflicts between concurrently executing transactions. Locks are mechanisms that ensure
that only one transaction can access a specific piece of data at a time, maintaining the ACID
properties, especially isolation.
One common locking protocol is 2-Phase Locking (2PL), which ensures that transactions
are serializable by using two distinct phases:
1. Growing Phase: A transaction can acquire locks but cannot release them.
2. Shrinking Phase: Once a transaction releases a lock, it cannot acquire any more
locks.
The two phases ensure that once a transaction starts releasing locks, it cannot interfere with
other transactions, which guarantees conflict serializability.
However, lock-based concurrency control can lead to a problem called deadlock. A
deadlock occurs when two or more transactions are each waiting for a lock held by the other,
causing a cycle of waiting that cannot be resolved without intervention. Detecting and
resolving deadlocks is a critical part of managing database systems.

📌 Key Concepts: 2-Phase Locking and Deadlock

2-Phase Locking (2PL)
 Definition: A protocol where transactions must acquire all the locks they need before
releasing any. This guarantees conflict serializability.
 Phases:
1. Growing Phase: A transaction can acquire locks, but cannot release them.
2. Shrinking Phase: After releasing a lock, the transaction cannot acquire any
more locks.
 Advantages:
o Ensures serializability by preventing cycles in transaction dependencies.
o Guarantees that the transactions are conflict-serializable.
 Disadvantages:
o May lead to deadlock, where transactions are waiting indefinitely for locks.
o Can result in lock contention, where many transactions are blocked, affecting
system performance.
Deadlock
 Definition: A situation where two or more transactions are waiting for each other to
release locks, creating a cycle of dependencies that prevents them from completing.
 Conditions for Deadlock (The Coffman Conditions):
1. Mutual Exclusion: Only one transaction can hold a lock at a time.
2. Hold and Wait: A transaction holding one lock is waiting for another.
3. No Preemption: Locks cannot be forcibly taken from a transaction.
4. Circular Wait: A circular chain of transactions exists, where each transaction is
waiting for the other to release a lock.
 Deadlock Prevention:
o Avoid circular waits by ordering lock acquisition.
 Use a timeout mechanism, where transactions are rolled back after a certain
o
wait period.
o Employ resource allocation graphs to detect cycles.
 Deadlock Detection:
o Detect deadlock through wait-for graphs or transaction dependency graphs.
o Once detected, deadlock can be resolved by killing one or more transactions.

✅ Summary of 2PL and Deadlock

Feature 2-Phase Locking (2PL) Deadlock
Definition Ensures conflict serializability by A situation where transactions are in a
acquiring locks in two phases cycle of waiting for each other
Phases Growing and Shrinking phases No specific phases, but results in
circular waiting
Benefits Guarantees serializability and Prevents conflicting transactions from
isolation happening simultaneously
Challenges Can lead to deadlock and lock Requires detection and resolution
contention mechanisms to prevent system hang
Example Transaction A locks data X, then Transaction A locks X, waits for Y, and
locks data Y transaction B locks Y, waits for X

Time Stamping Methods in DBMS

Definition:
Time stamping is a concurrency control method where each transaction is assigned a
unique timestamp. The order of transactions is determined by their timestamps, ensuring
that the serializability of operations is maintained — that is, the end result is the same as if
the transactions had been executed one after another in order of their timestamps.

📌 Key Concepts:
1. Timestamp (TS):
o Assigned to each transaction when it begins.
o Can be based on system clock or a logical counter.
2. Each data item X has:
o read_TS(X): the largest timestamp of any transaction that successfully read X.
o write_TS(X): the largest timestamp of any transaction that successfully wrote to
X.
⚖ Advantages of Timestamping:
 No deadlocks (non-blocking method).
 Maintains serializability.
⚠ Disadvantages:
 Higher abort rate (especially for older transactions).
 Overhead of maintaining multiple timestamps per data item.
What is Database Recovery Management?
Database Recovery Management refers to the set of techniques used to restore a database
to a correct state after a failure. It ensures that all committed transactions are preserved, and
all uncommitted transactions are undone, thereby maintaining the ACID properties
(especially Atomicity and Durability).

💥 Types of Failures That Require Recovery

1. Transaction Failure – Logical errors or system abort.
2. System Crash – Hardware or software failure causes system shutdown.
3. Media Failure – Disk crash or corruption of the database file.
4. Application Error – Bugs in code cause incorrect data updates.

🔁 Types of Recovery Techniques

1. Deferred Update (No changes made until commit):
o Changes are recorded in the log.
o Actual database is updated only after commit.
o On failure before commit → nothing to undo.
o On recovery → redo committed transactions from log.
2. Immediate Update:
o Updates are made to the database as they happen.
o A log is maintained for both old and new values.
o On failure:
o  Undo uncommitted transactions.
o  Redo committed ones.