Database Isolation Levels

Isolation levels control how transactions in a database are isolated from one another, ensuring data
consistency and preventing conflicts between concurrent transactions.

The isolation level option is specified using the statement

ISOLATION LEVEL <isolation>, where the value for <isolation> can be:
READ UNCOMMITTED: Lowest isolation, allows reading uncommitted data
READ COMMITTED: Only reads data that has been committed.
REPEATABLE READ: Ensures that data read once will not change during the transaction.
SERIALIZABLE: Highest isolation, guarantees complete isolation from other transactions.

Isolation levels are a critical aspect of database management systems, ensuring data consistency and
resolving potential conflicts in environments with concurrent transactions. Here's a detailed breakdown
of the isolation levels you mentioned:

1. READ UNCOMMITTED

Description: This is the lowest level of isolation. Transactions can read data that has not yet been
committed by other transactions.
Advantages: Minimal locking, higher performance for read-heavy operations.
Disadvantages: Risk of "dirty reads," where a transaction sees uncommitted changes from another
transaction, potentially leading to inconsistent or incorrect data.
Use Case: Situations where performance is prioritized over accuracy, such as logging systems.

2. READ COMMITTED

Description: Ensures that transactions only read data that has been committed. Uncommitted
changes are not visible to other transactions.
Advantages: Prevents dirty reads, providing a more consistent view of the data.
Disadvantages: Does not prevent "non-repeatable reads," where a value read by a transaction may
change if another transaction modifies it before the first transaction completes.
Use Case: Common in most applications where moderate consistency is sufficient.

3. REPEATABLE READ

Description: Guarantees that any data read by a transaction cannot be changed by other
transactions until the first transaction completes. Prevents both dirty reads and non-repeatable
reads.
Advantages: Provides stronger consistency for read operations.
Disadvantages: Does not protect against "phantom reads," where new rows matching a query
condition may appear if another transaction inserts them.
Use Case: Scenarios requiring consistent data across multiple reads, such as generating reports.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 1/65
4. SERIALIZABLE

Description: The highest level of isolation. Ensures complete isolation by serializing transactions,
making them execute one after another.
Advantages: Prevents dirty reads, non-repeatable reads, and phantom reads, ensuring maximum
consistency.
Disadvantages: High overhead due to extensive locking, potentially reducing concurrency and
performance.
Use Case: Applications where data consistency is critical, such as financial systems.

Comparison of Isolation Levels

Isolation Level Dirty Read Non-Repeatable Read Phantom Read

READ UNCOMMITTED Yes Yes Yes

READ COMMITTED No Yes Yes

REPEATABLE READ No No Yes

SERIALIZABLE No No No

Choosing the appropriate isolation level involves balancing performance and consistency
requirements for your specific application.

Phantoms:
A transaction T1 may read a set of rows from a table, perhaps based on some condition specified in
the SQL WHERE-clause.
Suppose that a transaction T2 inserts a new row r that also satisfies the WHERE-clause condition
used in T1, into the table used by T1.
The record r is called a phantom record because it was not there when T1 starts but is there when
T1 ends. T1 may or may not see the phantom, a row that previously did not exist.
If the equivalent serial order is T1 followed by T2, then the record r should not be seen; but if it is T2
followed by T1,then the phantom record should be in the result given to T1. If the system cannot
ensure the correct behavior, then it does not deal with the phantom record problem.
explain wiith examples

Understanding Phantoms with an Example

Phantoms occur when a transaction reads a set of rows matching a specific condition, and another
concurrent transaction modifies the dataset in a way that introduces new rows matching the condition.
The first transaction may or may not see the new rows depending on the timing and isolation level.

Example Scenario

Initial Setup

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 2/65
Imagine a table `Employees` with the following data:

ID Name Department
1 Alice HR

2 Bob IT
3 Charlie HR

Transaction T1

Transaction `T1` runs a query to count the number of employees in the HR department:

sql

SELECT COUNT(*) FROM Employees WHERE Department = 'HR';

Result: `2` (Alice and Charlie).

Transaction T2

While `T1` is still active, transaction `T2` inserts a new employee into the HR department:

sql

INSERT INTO Employees (ID, Name, Department) VALUES (4, 'Diana', 'HR');

Impact of Phantom Rows

Case 1: T1 Reads Again After T2

If `T1` executes the same query again before it commits, depending on the isolation level:
Lower isolation levels (e.g., READ COMMITTED): The new row (`Diana`) may be visible.
Result: `3` (Alice, Charlie, and Diana).
Higher isolation levels (e.g., REPEATABLE READ or SERIALIZABLE): The new row (`Diana`)
will not be visible because `T1` is isolated from the changes made by `T2`.
Result: `2` (Alice and Charlie).
Correct Serial Order:
If `T1` is logically before `T2`, the phantom (`Diana`) should not be seen.
If `T2` is logically before `T1`, the phantom (`Diana`) should be seen.

Handling Phantoms with Isolation Levels

READ COMMITTED:
Phantoms are not addressed; `T1` may see the new row if it reads again after `T2` commits.
REPEATABLE READ:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 3/65
 Ensures that rows read during a transaction remain consistent. However, phantoms can still
occur because new rows can be added.
SERIALIZABLE:
Completely prevents phantoms by locking the range of rows that match the `WHERE` condition,
ensuring no new rows can be inserted or deleted in the range.

Implementation Example: SERIALIZABLE

To ensure no phantoms, the database uses range locks. For example:

1. When `T1` executes:

sql

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SELECT COUNT(*) FROM Employees WHERE Department = 'HR';

The system locks all rows in the HR department and prevents `T2` from inserting new rows
matching the condition.
2. If `T2` tries:

sql

INSERT INTO Employees (ID, Name, Department) VALUES (4, 'Diana', 'HR');

The operation is blocked until `T1` completes.

Conclusion

Phantom records occur when a transaction observes new rows that did not exist at the beginning of the
transaction. SERIALIZABLE is the only isolation level that fully prevents phantom issues by locking the
query's result set and range, ensuring consistency even with concurrent modifications.

and why using transaction is immportant , why can't we tyoe codes directly

Using transactions in database operations is important because they provide a structured way to handle
multiple operations as a single unit of work, ensuring data integrity, consistency, and isolation.
Simply typing SQL commands without transactions might work for simple cases but can lead to serious
issues in multi-user or complex environments.

Why Transactions are Important

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 4/65
1. Atomicity (All-or-Nothing Execution)

Transactions ensure that either all operations within a transaction are completed successfully or
none are applied.
Without Transactions: If a process is interrupted (e.g., due to a crash), only some commands may
execute, leaving the database in an inconsistent state.
Example:

sql

-- Transferring money between accounts

UPDATE Accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE Accounts SET balance = balance + 100 WHERE account_id = 2;

If the first `UPDATE` succeeds but the second fails, the system will lose $100 unless the operations
are wrapped in a transaction.

2. Consistency

Transactions ensure that the database moves from one consistent state to another. Constraints
(e.g., foreign keys, unique keys) are enforced throughout the transaction.
Without Transactions: Partial operations could violate constraints, resulting in corrupt data.

3. Isolation (Handling Concurrency)

Transactions prevent interference between operations performed by different users.

Without Transactions: Concurrent modifications can result in:
Dirty Reads: Reading uncommitted changes from another transaction.
Non-Repeatable Reads: Seeing different data in the same transaction.
Phantoms: New rows appear unexpectedly.
Example:

sql

-- Two users book the last available seat in a theater simultaneously.

SELECT seats_available FROM Shows WHERE show_id = 101;
UPDATE Shows SET seats_available = seats_available - 1 WHERE show_id = 101;

Without isolation, both users could see the same available seat and double-book it.

4. Durability

Once a transaction commits, its changes are guaranteed to persist, even in the event of a system
crash.
Without Transactions: Changes made during a crash might be lost or incomplete.

Why Can't We Just Type SQL Commands Directly?

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 5/65
1. Lack of Error Handling

SQL commands executed individually lack mechanisms to rollback changes if an error occurs in a
sequence of operations.
Example: If you manually update multiple tables and one fails, you must manually identify and
undo the previous changes, which is error-prone and time-consuming.

2. Complex Business Logic

Many real-world operations involve multiple steps (e.g., transferring funds, placing orders).
Handling these manually is cumbersome and risky. Transactions ensure that either all related
operations are completed or none are.

3. Data Corruption Risk

Without transactions, partial updates can corrupt data. For example, if a system crashes midway
through a multi-step operation, the database may be left in an inconsistent state.

4. Concurrency Issues

Typing SQL commands directly does not handle simultaneous user access effectively. Transactions
ensure isolation and prevent race conditions.

5. Auditing and Debugging

Transactions provide a clear boundary for a set of operations, making it easier to audit and debug
issues.

Example: Using Transactions

Without Transaction

sql

UPDATE Accounts SET balance = balance - 500 WHERE account_id = 1;

UPDATE Accounts SET balance = balance + 500 WHERE account_id = 2;
-- Crash occurs here: $500 is deducted from account 1 but not added to account 2.

With Transaction

sql

START TRANSACTION;
UPDATE Accounts SET balance = balance - 500 WHERE account_id = 1;
UPDATE Accounts SET balance = balance + 500 WHERE account_id = 2;
COMMIT; -- Ensures all changes are applied only when both operations succeed.

If a crash occurs, the changes are not committed, and the database remains consistent.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 6/65
Conclusion

Using transactions is essential for ensuring that database operations are reliable, consistent, and safe,
especially in multi-user or complex environments. Typing SQL commands directly without transactional
safeguards is error-prone and risks data corruption, inconsistency, and concurrency issues.

The System Log

The System Log

Each database modification made by a transaction is first recorded in the log.

We record the identifier of the transaction performing the modification, the identifier of the data
item being modified, and both the old value (prior to modification) and the new value (after
modification) of the data item.

Only then is the database itself modified. Maintaining a log provides the possibility of redoing a
modification to ensure atomicity and durability as well as the possibility of undoing a modification
to ensure atomicity in case of a failure during transaction execution
with examples

The System Log in Transaction Management

The system log plays a vital role in ensuring the atomicity and durability of transactions in a database.
By recording each database modification before it is applied, the system can recover from failures and
maintain a consistent state.

Components of the System Log

For each modification, the log typically records:

1. Transaction ID: Identifier for the transaction performing the operation.

2. Data Item: Identifier for the modified data.
3. Old Value: The value of the data before modification.
4. New Value: The value of the data after modification.
5. Action Type: Type of operation (`UPDATE`, `INSERT`, or `DELETE`).

Why Use a System Log?

1. Atomicity: Ensures that all operations in a transaction either complete fully or have no effect at all.
2. Durability: Guarantees that committed changes are permanent, even in the event of a crash.
3. Recovery:
Redo: Reapply changes to ensure committed transactions persist.
Undo: Revert uncommitted changes if a transaction fails.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 7/65
Example: System Log in Action

Initial Setup

Consider a table `Accounts` with the following data:

Account_ID Balance
101 5000

102 3000

Transaction T1: Transferring $1000 from Account 101 to Account 102

Steps performed:

1. Deduct $1000 from Account 101.

2. Add $1000 to Account 102.

Log Records

1. Before Modification
Transaction ID: T1
Action: `UPDATE`
Data Item: `Account 101`
Old Value: 5000
New Value: 4000
Log Entry:

yaml

T1, UPDATE, Account 101, Old Value: 5000, New Value: 4000

2. After Modification
Transaction ID: T1
Action: `UPDATE`
Data Item: `Account 102`
Old Value: 3000
New Value: 4000
Log Entry:

yaml

T1, UPDATE, Account 102, Old Value: 3000, New Value: 4000

System Log in Failure Scenarios

1. Failure Before Commit

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 8/65
If the system crashes before the transaction commits:

Undo: Use the log to revert the changes.

Rollback Account 101 to 5000.
Rollback Account 102 to 3000.

2. Failure After Commit

If the system crashes after the transaction commits:

Redo: Use the log to reapply the changes.

Update Account 101 to 4000.
Update Account 102 to 4000.

System Log Example in SQL

Transaction

sql

START TRANSACTION;

-- Step 1: Deduct from Account 101

UPDATE Accounts SET Balance = Balance - 1000 WHERE Account_ID = 101;

-- Step 2: Add to Account 102

UPDATE Accounts SET Balance = Balance + 1000 WHERE Account_ID = 102;

COMMIT;

Corresponding Log Entries

1. Log Entry for Account 101:

yaml

T1, UPDATE, Account 101, Old Value: 5000, New Value: 4000

2. Log Entry for Account 102:

yaml

T1, UPDATE, Account 102, Old Value: 3000, New Value: 4000

Recovery Using the Log

Undo Operations

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 9/65
If the system crashes during `T1`:

1. Check the log.

2. Revert:
Account 101: Set balance back to 5000.
Account 102: Set balance back to 3000.

Redo Operations

If the system crashes after `T1` commits:

1. Check the log.

2. Reapply:
Account 101: Deduct balance to 4000.
Account 102: Add balance to 4000.

Conclusion

The system log ensures reliable transaction processing by maintaining a record of changes before
applying them to the database. This enables:

Recovery from failures.

Enforcement of atomicity and durability.
Maintenance of database consistency.

Atomicity requirement
If the transaction fails after step 3 and before step 6, money will be “lost” leading to an inconsistent
database state
Failure could be due to software or hardware
The system should ensure that updates of a partially executed transaction are not reflected in the
database.
If the atomicity property is present, all actions of the transaction are reflected in the database, or
none are
The basic idea behind ensuring atomicity is this: The database system keeps track (on disk) of the
old values of any data on which a transaction performs a write. This information is written to a file
called the log.
If the transaction does not complete its execution, the database system restores the old values
from the log to make it appear as though the transaction never executed. Ensuring atomicity is the
responsibility of the database system; specifically, it is handled by a component of the database
called the recovery system.

Durability: Once the user has been notified that the transaction has completed (i.e., the transfer of
the $50 has taken place), the updates to the database by the transaction must persist even if there
are software or hardware failures. The recovery system of the database, is responsible for ensuring
durability, in addition to ensuring atomicity.

Consistency:
The sum of A and B is unchanged by the execution of the transaction

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 10/65
 In general, consistency requirements include
Explicitly specified integrity constraints such as primary keys and foreign keys
Implicit integrity constraints
A transaction must see a consistent database.
During transaction execution the database may be temporarily inconsistent.
When the transaction completes successfully the database must be consistent

Detailed Explanation of Atomicity, Durability, and Consistency

These properties are part of the ACID principles (Atomicity, Consistency, Isolation, Durability), which
ensure reliable transaction processing in a database. Let’s break them down with examples and their
importance.

1. Atomicity

Definition:
Atomicity ensures that all steps in a transaction are executed successfully as a single unit or none at all.
If any step fails, all previous operations are rolled back, leaving the database unchanged.

Key Points:

Prevents partial updates to the database.

Relies on a system log to store the old values of data before changes are applied.
Handled by the recovery system of the database.

Example: Bank Transfer

Imagine transferring $50 from Account A to Account B:

Account Initial Balance After Transfer

A $100 $50
B $200 $250

Transaction Steps:

1. Deduct $50 from Account A: `UPDATE Accounts SET balance = balance - 50 WHERE account_id = A;`
2. Add $50 to Account B: `UPDATE Accounts SET balance = balance + 50 WHERE account_id = B;`
3. Commit the transaction.

Failure Scenario:
If a failure occurs after step 1 (deducting $50 from Account A) but before step 2 (adding $50 to Account
B), the database will have an inconsistent state where $50 has "disappeared."

Atomicity Solution:
The recovery system uses the log to restore the old value of Account A ($100), ensuring no partial
changes are reflected.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 11/65
2. Durability

Definition:
Durability ensures that once a transaction is committed, its changes persist in the database, even in the
event of a system crash or failure.
Key Points:

Updates are written to non-volatile storage (disk) before notifying the user.
Handled by the recovery system, which ensures committed changes are not lost.

Example: Completed Transfer

Suppose the transaction transferring $50 from Account A to Account B completes successfully, and the
user is notified.

Account Final Balance

A $50
B $250

Failure Scenario:
If the system crashes immediately after the user is notified, the database might lose recent changes if
they are only stored in volatile memory.
Durability Solution:
The recovery system ensures that all committed changes are written to disk (log or database files) so
that they persist after recovery.

3. Consistency

Definition:
Consistency ensures that a transaction maintains the integrity constraints of the database, preserving
the logical correctness of the data.

Key Points:

Explicit constraints: Primary keys, foreign keys, unique constraints.

Implicit constraints: Business rules, such as maintaining accurate balances.

Example: Ensuring Balance Consistency

In the bank transfer example, the sum of balances in Accounts A and B must remain $300, regardless
of transaction execution.

Consistency Phases:

Before Transaction: The database is consistent (e.g., A = $100, B = $200).

During Execution: Temporary inconsistency may occur (e.g., A = $50, B = $200).
After Completion: The database is consistent again (e.g., A = $50, B = $250).

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 12/65
Failure Scenario:
If the transaction fails midway and leaves the sum unequal to $300, the database is inconsistent.
Consistency Solution:
Atomicity and durability ensure that all changes are applied together or rolled back, maintaining
consistency.

Key Role of the Recovery System

The recovery system ensures atomicity and durability:

1. Atomicity:
Uses the log to track old values before applying changes.
If the transaction fails, the system undoes changes using the log.
2. Durability:
Ensures changes are written to persistent storage before committing.
After a crash, it reapplies committed changes (redo operations).

Example of Log Entries

For transferring $50 from A to B:

1. Log old value of A:

sql

T1, UPDATE, Account A, Old Value: 100, New Value: 50

2. Log old value of B:

sql

T1, UPDATE, Account B, Old Value: 200, New Value: 250

Summary

Property What It Ensures Key Mechanism

A transaction is all-or-nothing. No partial changes are reflected Undo operations via system
Atomicity
in the database. log.

Changes made by a committed transaction persist, even after a Redo operations via system
Durability
failure. log.
The database moves from one consistent state to another, Supported by
Consistency
satisfying all integrity constraints. atomicity/durability.

These properties together ensure reliable, fault-tolerant transaction processing in databases.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 13/65
 Isolation — if between steps 3 and 6, another transaction T2 is allowed to access the partially
updated database, it will see an inconsistent database (the sum A + B will be less than it should be).
T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B)

Isolation can be ensured trivially by running transactions serially. That is, one after the other.
However, executing multiple transactions concurrently has significant benefits.

Understanding Isolation with Example

Definition of Isolation:
Isolation ensures that a transaction is not affected by other concurrent transactions. When multiple
transactions execute simultaneously, the database system ensures that their intermediate states remain
invisible to one another, preserving consistency.

Example: Bank Transfer

Consider two transactions:

T1: Transfers $50 from Account A to Account B.

T2: Reads the balances of Account A and Account B and calculates their sum.

Step-by-Step Execution Without Isolation:

1. T1 starts:
Reads Account A (`read(A) = $100`).
Deducts $50 from A (`A = $100 - $50 = $50`).
Writes the updated A (`write(A) = $50`).
2. T2 starts (concurrently):
Reads Account A (`read(A) = $50`).
Reads Account B (`read(B) = $200`).
Prints the sum (`A + B = $50 + $200 = $250`).
3. T1 resumes:
Reads Account B (`read(B) = $200`).
Adds $50 to B (`B = $200 + $50 = $250`).
Writes the updated B (`write(B) = $250`).

Problem:

T2 sees an inconsistent state:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 14/65
 It observes the updated value of A but the old value of B, leading to an incorrect sum (`$250`
instead of `$300`).

Ensuring Isolation

Approach 1: Serial Execution

Transactions are executed one at a time in the following order:

T1 completes entirely, ensuring A = $50 and B = $250.

T2 starts, calculating the correct sum (`A + B = $300`).

Drawback:
Serial execution is inefficient because transactions must wait, leading to poor utilization of system
resources.

Approach 2: Concurrency with Isolation Levels

Modern databases allow transactions to execute concurrently while maintaining isolation using
mechanisms like locks or MVCC (Multi-Version Concurrency Control).

Isolation Level Effect

Read Uncommitted T2 can see uncommitted changes by T1, leading to incorrect results (sum = $250).
Read Committed T2 sees only committed changes, avoiding partially updated states.
Repeatable Read T2 sees the same value for A and B throughout its execution, avoiding anomalies.

Serializable T2 runs as if transactions are serial, ensuring the sum is $300.

Benefits of Concurrency

Executing transactions concurrently is advantageous:

1. Improved Throughput: More transactions can be processed in the same time.

2. Reduced Waiting: Transactions don’t need to wait for others to complete.
3. Better Resource Utilization: Database resources like CPU and I/O are used more effectively.

Example:
If a database handles thousands of bank transfers (T1) and balance queries (T2), serial execution would
delay all operations. Concurrency allows the system to handle many transactions efficiently while
maintaining isolation.

Summary

With Isolation Without Isolation

T2 will see a consistent state of the database. T2 might see an inconsistent state (A = $50, B = $200).

Sum calculation will be correct ($300). Sum calculation could be incorrect ($250).

Concurrency with proper isolation mechanisms ensures consistency without sacrificing performance.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 15/65
 A collection of several operations on the database appears to be a single unit from the point of view
of the database user. However, within the database system it consists of several operations.

Example: A transfer of funds from a checking account to a savings account is a single operation
from the customer’s standpoint, however, within the database system it consists of several
operations.

Collections of operations that form a single logical unit of work are called transactions.
A collection of several operations on the database appears to be a single unit from the point of view
of the database user. However, within the database system it consists of several operations.

Example: A transfer of funds from a checking account to a savings account is a single operation
from the customer’s standpoint, however, within the database system it consists of several
operations.

Collections of operations that form a single logical unit of work are called transactions.
Schedules

Schedules

Schedule – a sequences of instructions that specify the chronological order in

which instructions of concurrent transactions are executed
A schedule for a set of transactions must consist of all instructions of those transactions
Must preserve the order in which the instructions appear in each individual transaction.
A transaction that successfully completes its execution will have a commit
instructions as the last statement
By default transaction assumed to execute commit instruction as its last step
A transaction that fails to successfully complete its execution will have an abort
instruction as the last statement

Schedule

A schedule (or history) S of n transactions T1, T2, … , Tn is an ordering of the operations of the
transactions.
Operations from different transactions can be interleaved in the schedule S.
For each transaction Ti that participates in the schedule S, the operations of Ti in S must appear in
the same order in which they occur in Ti.
The order of operations in S is considered to be a total ordering, meaning that for any two
operations in the schedule, one must occur before the other.

Schedules

Read-Write Conflict: Occurs when a read and a write operation on the same data item from different
transactions, where changing the order alters the value read.

Write-Write Conflict: Happens when two write operations on the same data item from different
transactions, with the final value depending on the order of execution. 1

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 16/65
 Schedule

Conflicting Operations in a Schedule.

Two operations in a schedule are said to conflict if they satisfy all three of the following conditions:
they belong to different transactions;
they access the same item X; and
at least one of the operations is a write_item(X).

For example, in schedule

Sa: r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y)
Sb: r1(X); w1(X); r2(X); w2(X); r1(Y);
the operations r1(X) and w2(X) conflict, as do the operations r2(X) and w1(X), and the operations
w1(X) and w2(X). However, the operations r1(X) and r2(X) do not conflict, since they are both read,
the operations w2(X) and w1(Y) do not conflict because they operate on distinct data items X and Y;
and the operations r1(X) and w1(X) do not conflict because they belong to the same transaction.
Consider again the simplified banking system, which has several accounts, and a set of
transactions that access and update those accounts.

Let T1 and T2 be two transactions that transfer funds from one account to another. Transaction T1
transfers $50 from account A to account B.

Transaction T2 transfers 10 percent of the balance from account A to

account B.
schedule 2:
Suppose the current values of accounts A and B are $1000 and
$2000, respectively.

Suppose also that the two transactions are executed one at a time in the order T1 followed by T2.
This execution sequence appears in Figure.

In the figure, the sequence of instruction steps is in chronological order from top to bottom,
with instructions of T1 appearing in the left column and instructions of T2 appearing in the right
column.

The final values of accounts A and B, after the execution in Figure 17.2 takes place, are $855 and
$2145, respectively. Thus, the total amount of money in accounts A and B— that is, the sum A + B
—is preserved after the execution of both transactions.
Schedule 3

Let T1 and T2 be the transactions defined previously. The following schedule is not a serial schedule,
but it is equivalent to Schedule 1

Suppose that the two transactions are executed

concurrently. One possible schedule appears in Figure.

After this execution takes place, we arrive at the same state as the one in which the transactions are
executed serially in the order T1 followed by T2. The sum A + B is indeed preserved.
Schedule 4

In Schedules 1, 2 and 3, the sum A + B is preserved, whereas this schedule does not preserve A+B
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 17/65
 Not all concurrent executions result in a correct state. To
illustrate, consider the schedule of Figure.

After the execution of this schedule, we arrive at a state

where the final values of accounts A and B are $950 and
$2100, respectively. This final state is an inconsistent state, since we have gained $50 in the
process of the concurrent execution. Indeed, the sum A + B is not
preserved by the execution of the two transactions.

It is the job of the database system to ensure that any schedule that is executed will leave the
database in a consistent state.

The concurrency-control component of the database system

carries out this task.
Serial Schedules
Formally, a schedule S is serial if, for every transaction T participating in the schedule, all the
operations of T are executed consecutively in the schedule;
otherwise, the schedule is called nonserial.
Therefore, in a serial schedule, only one transaction at a time is active—the commit (or abort) of the
active transaction initiates execution of the next transaction.
No interleaving occurs in a serial schedule.

All the transactions execute serially one after the other.

When one transaction executes, no other transaction is allowed to execute.

Non Serial Schedules

Multiple transactions execute concurrently.

Operations of all the transactions are inter leaved or mixed with each
other.
Non Serial schedules are NOT always Consistent
Example:

explain all the in examples and make make simple bullet points and explained detailed

Understanding Transactions and Schedules

Transactions

A transaction is a logical unit of work in a database, consisting of multiple operations that appear
as a single operation to the user.
Example: Transferring $50 from Account A to Account B includes:
Deducting $50 from A.
Adding $50 to B.
These steps form a single logical transaction.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 18/65
Schedules

A schedule defines the order in which operations from multiple transactions are executed, ensuring
consistency and correctness.

Key Points about Schedules:

1. Order of Operations:
Operations from different transactions can interleave in the schedule.
However, the operations of an individual transaction must remain in the original order.
2. Commit and Abort:
If a transaction successfully completes, its last step is `COMMIT`.
If it fails, its last step is `ABORT`.

Conflicts in Schedules

Conflicts arise when the operations from different transactions overlap, potentially leading to incorrect
results.

Types of Conflicts:

1. Read-Write Conflict:
A transaction reads a value, and another transaction writes to the same value.
Example:
Transaction T1 reads `X`.
Transaction T2 writes `X`.
If the order changes, T1 may read an outdated or incorrect value.
2. Write-Write Conflict:
Two transactions write to the same value.
Example:
T1 writes `X`.
T2 writes `X`.
The final value of `X` depends on the order of execution.

Example Schedule:

Schedule Sa: `r1(X); r2(X); w1(X); r1(Y); w2(X); w1(Y)`

Conflicts:
`r1(X)` and `w2(X)` (Read-Write conflict).
`r2(X)` and `w1(X)` (Read-Write conflict).
`w1(X)` and `w2(X)` (Write-Write conflict).

Serial and Non-Serial Schedules

1. Serial Schedules

Definition:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 19/65
 All operations of one transaction are executed before another transaction begins.
No interleaving of operations occurs.
Example:
T1 transfers $50 from A to B.
T2 transfers 10% of A’s balance to B.
Execution:
1. T1 completes entirely:
A = $950, B = $2050.
2. T2 starts:
A = $855, B = $2145.
Result:
Final state is consistent.
Total sum: A + B = $3000.

2. Non-Serial Schedules

Definition:
Operations of multiple transactions are interleaved.
Example:
T1 and T2 execute concurrently:
1. T1 deducts $50 from A and writes the result.
2. T2 reads A (updated by T1) and calculates 10% of A.
3. T1 adds $50 to B.
4. T2 writes updated values.
Result:
Final state is consistent.
Total sum: A + B = $3000.

Key Differences:

Aspect Serial Non-Serial

Execution Order Transactions execute one after another. Transactions are interleaved.

Consistency Always consistent. Not always consistent.

Performance Slower, as transactions wait for others. Faster due to concurrency.

Example Schedules

Schedule 1 (Serial):

T1 transfers $50, then T2 transfers 10% of A.

Final state:
A = $855, B = $2145.
Consistent: A + B = $3000.

Schedule 2 (Non-Serial, Equivalent to Schedule 1):

Interleaved execution:
T1 deducts $50 from A → T2 reads A → T1 adds $50 to B → T2 updates B.
Final state:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 20/65
 A = $855, B = $2145.
Consistent: A + B = $3000.

Schedule 3 (Non-Serial, Not Consistent):

T1 deducts $50 from A → T2 calculates 10% of the old value of A → T1 adds $50 to B → T2 writes to
B.
Final state:
A = $950, B = $2100.
Inconsistent: A + B = $3050 (gain of $50).

Concurrency Control

The concurrency-control component of the database ensures that schedules preserve

consistency.
Ensures that:
1. Only serializable schedules are allowed.
2. Transactions do not interfere with each other’s results.

Summary of Schedules

Schedule Type Order of Execution Consistency Concurrency Allowed?

Serial One transaction at a time. Always consistent. No

Non-Serial Equivalent Interleaved, but equivalent to serial. Consistent. Yes

Non-Serial Conflict Interleaved, but causes inconsistency. Inconsistent. Yes

Proper concurrency control ensures that non-serial schedules maintain the correctness and consistency
of the database.

Uploaded image
Problem with serial schedules
Limit concurrency by prohibiting interleaving of operations
Unacceptable in practice
Solution: determine which schedules are equivalent to a serial
schedule and allow those to occur
Serializable schedule of n transactions
Equivalent to some serial schedule of same n transactions

Result equivalent
schedules
Produce the same final state of the database
May be accidental
Cannot be used alone to define equivalence of schedules
Conflict equivalence of two schedules.
Relative order of any two conflicting operations is the same in both schedules.
If two conflicting operations are applied in different orders in two schedules, the effect can be
different on the database or on the transactions in the schedule, and hence the schedules are not
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 21/65
 conflict equivalent.
Serializable schedules
Schedule S is serializable if it is conflict equivalent to some serial schedule S’.

Serializability in DBMS

Some non-serial schedules may lead to inconsistency of the database.

Serializability is a concept that helps to identify which non-serial schedules are correct and will
maintain the consistency of the database.
Serializable Schedules

If a given non-serial schedule of ‘n’ transactions is equivalent to some serial

schedule of ‘n’ transactions, then it is called as a serializable schedule.
Serial Schedules
Serializable Schedules
No concurrency => all the transactions necessarily execute serially one after the other.

Concurrency => multiple transactions

can execute concurrently.
Serial schedules lead to less resource utilization and CPU throughput.
Serializable schedules improve both resource utilization and CPU throughput.

Serial Schedules are less efficient as

compared to serializable schedules.

Serializable Schedules are always

better than serial schedules.

Equivalence Schedule

For two schedules to be equivalent, the operations applied to each data item affected by the
schedules should be applied to that item in both schedules in the same order.
Two definitions of equivalence of schedules are generally used:
conflict equivalence and view equivalence
Conflict Equivalence of Two Schedules. Two schedules are said to be conflict equivalent if the
relative order of any two conflicting operations is the same in both schedules.
If two conflicting operations are applied in different orders in two schedules, the effect can be
different on the database or on the transactions in the schedule, and hence the schedules are not
conflict equivalent
Serializability

Before we can consider how the concurrency-control component of the database system can ensure
serializability, we consider how to determine when a schedule is serializable.

Certainly, serial schedules are serializable, but if steps of multiple transactions are interleaved, it is
harder to determine whether a schedule is serializable.

Since transactions are programs, it is difficult to determine exactly what

operations a transaction performs and how operations of various transactions interact.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 22/65
 For this reason, we shall not consider the various types of operations that a transaction can perform
on a data item, but instead consider only two operations: read and write.

We assume that, between a read(Q) instruction and a write(Q) instruction on a data item Q, a
transaction may perform an arbitrary sequence of operations on the copy of Q that is residing in the
local buffer of the transaction.
Serializability

Basic Assumption – Each transaction preserves database consistency.

Thus, serial execution of a set of transactions preserves database consistency.
A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule.
Different forms of schedule equivalence give rise to the notions of:
Conflict serializability
Our simplified schedules consist of only read and write instructions.
Let us consider a schedule S in which there are two consecutive instructions, I and J, of transactions
Ti and Tj , respectively (i ≠ j). If I and J refer to different data items, then we can swap I and J without
affecting the results of any instruction in the schedule.
However, if I and J refer to the same data item Q, then the order of the two steps may matter. Since
we are dealing with only read and write instructions, there are four cases that we need to consider:
Conflicting Instructions

Instructions li and lj of transactions Ti and Tj respectively, conflict if and only if there exists some
item Q accessed by both li and lj, and at least one of these instructions wrote Q.
li = read(Q), lj = read(Q). li and lj don’t conflict.
li = read(Q), lj = write(Q). They conflict.
li = write(Q), lj = read(Q). They conflict
li = write(Q), lj = write(Q). They conflict
Intuitively, a conflict between li and lj forces a (logical) temporal order between them.
If li and lj are serial in a schedule and they do not conflict, their results would remain the same even
if they had been interchanged in the schedule.
Conflict Serializability

If a schedule S can be transformed into a schedule S’ by a series of swaps of non-conflicting

instructions, we say that S and S’ are conflict equivalent.

We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule

We say that I and J conflict if they

Conflict Serializability

Schedule 3 can be transformed into Schedule 6, a serial schedule where T2 follows T1, by series of
swaps of non-conflicting instructions. Therefore Schedule 3 is conflict serializable.
Since the write(A) instruction of T2 in schedule 3 of Figure, does not conflict with the read(B)
instruction of T1, we can swap these instructions to generate an equivalent schedule,
schedule 5, in Figure. Regardless of the initial system state, schedules 3 and 5 both produce the
same final system state.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 23/65
 Example of a schedule that is not conflict serializable:
We are unable to swap instructions in the above schedule to obtain either the serial schedule
< T3, T4 >, or the serial schedule < T4, T3 >.
If a given non-serial schedule can be converted into a serial schedule by swapping its non-
conflicting operations, then it is called as a conflict serializable schedule.

Conflict Serializability: Conflicting Operations

Two operations are called as conflicting operations if

all the following conditions hold true for them-

✔Both the operations belong to different transactions

✔Both the operations are on the same data item
✔At least one of the two operations is a write operation
Conflict Serializability: Conflicting Operations

Two operations are called as conflicting operations if

all the following conditions hold true for them-

✔Both the operations belong to different transactions

✔Both the operations are on the same data item
✔At least one of the two operations is a write operation
Conflict Serializability: Conflicting Operations Examples

Conflicting operations pair (R1(A), W2(A)) because they belong to two different transactions on same
data item A and one of them is write operation.

Similarly, (W1(A), W2(A)) and (W1(A), R2(A)) pairs are

also conflicting.

On the other hand, (R1(A), W2(B)) pair is non-conflicting because they operate on different data
item.

Similarly, ((W1(A), W2(B)) pair is non-conflicting.

Testing conflict serializability of a schedule:

1. For each transaction Ti participating in schedule S, create a node labeled Ti in the precedence
graph.
2. For each case in S where Tj executes a read_item(X) after Ti executes a write_item(X), create an
edge (Ti → Tj) in the precedence graph.
3. For each case in S where Tj executes a write_item(X) after Ti executes a read_item(X), create an
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 24/65
 edge (Ti → Tj) in the precedence graph.
4. For each case in S where Tj executes a write_item(X) after Ti executes a write_item(X), create an
edge (Ti → Tj) in the precedence graph.
5. The schedule S is serializable if and only if the precedence graph has no cycles.

Follow the following steps to check whether a given non-serial schedule is conflict serializable or
not-

Step-01: Find and list all the conflicting operations.

Step-02: Start creating a precedence graph by drawing one node for each
transaction.

Step-03: Draw an edge for each conflict pair such that if Xi (V) and Yj (V) forms a conflict pair then
draw an edge from Ti to Tj. This ensures that Ti gets executed before Tj.

Step-04: Check if there is any cycle formed in the graph.

If there is no cycle found, then the schedule is conflict serializable
otherwise not.

Explain this all in detailed with all points line by line in detailed simple words . with examples if
required exaplain

The content explains Conflict Serializability and its role in Database Management Systems (DBMS).
Let me break it down step by step in simple words.

1. What is Serializability?

Definition: Serializability ensures that a non-serial schedule (where transactions are interleaved)
behaves as if the transactions were executed in a serial schedule (one transaction at a time).
Why Important? Non-serial schedules can improve performance by allowing concurrency, but
they must ensure database consistency. Serializability helps us identify which non-serial
schedules are correct.

2. Serial vs Serializable Schedules

Serial Schedule:
Transactions execute one after the other, without overlapping.
Example:

css

T1: Read(A), Write(A)

T2: Read(B), Write(B)

Serializable Schedule:
Transactions overlap but produce the same final database state as a serial schedule.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 25/65
 Example (overlapping operations):

css

T1: Read(A)
T2: Write(B)
T1: Write(A)

This is acceptable if it doesn’t cause conflicts.

3. Conflict Serializability

A schedule is conflict serializable if it can be transformed into a serial schedule by swapping

non-conflicting operations.
Key Idea: Swap operations to make the schedule behave like a serial one, while ensuring no
conflicting operations are out of order.

4. What are Conflicting Operations?

Two operations are conflicting if all the following conditions are true:

1. Belong to different transactions (e.g., T1 and T2).

2. Operate on the same data item (e.g., A).
3. At least one of the operations is a write.

Examples:

1. Conflicting:
`R1(A)`and `W2(A)` (Read by T1, Write by T2 on A).
`W1(A)` and `W2(A)` (Writes by T1 and T2 on A).
`W1(A)` and `R2(A)` (Write by T1, Read by T2 on A).
2. Non-Conflicting:
`R1(A)` and `W2(B)` (Operate on different data items, A and B).
`W1(A)` and `W2(B)` (Different data items).

5. Steps to Check Conflict Serializability

To check if a schedule is conflict serializable, follow these steps:

Step 1: List Conflicting Operations

Identify all pairs of conflicting operations in the schedule.

Step 2: Create a Precedence Graph

Draw one node for each transaction (e.g., T1, T2).

Add directed edges for each conflict:
If Tj executes `read/write` after Ti’s `write` on the same item, draw an edge `Ti → Tj`.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 26/65
Step 3: Check for Cycles

If the precedence graph has no cycles, the schedule is conflict serializable.

If there is a cycle, the schedule is not conflict serializable.

6. Example

Example Schedule:

css

T1: Read(A), Write(A)

T2: Read(A), Write(A)

Conflicts:
`R1(A)` and `W2(A)` → Conflict, edge T1 → T2.
`W1(A)` and `R2(A)` → Conflict, edge T2 → T1.

Precedence Graph:

Nodes: T1, T2.

Edges: T1 → T2 and T2 → T1 (cycle exists).

Result: The schedule is not conflict serializable because the graph has a cycle.

7. Advantages of Serializable Schedules

Allows concurrent transactions while ensuring correctness.

Improves resource utilization and throughput compared to serial schedules.
Prevents inconsistencies in the database.

8. Conclusion

Conflict serializability is a practical way to determine whether a non-serial schedule can be executed
safely. By identifying conflicts and checking for cycles in the precedence graph, we can ensure database
consistency even with concurrent transactions.

ransaction Isolation and Atomicity

Recoverable Schedule

Cascadeless Schedule

If a transaction Ti fails, for whatever reason, we need to undo the effect of this transaction to ensure
the atomicity property of the transaction.
In a system that allows concurrent execution, the atomicity property requires that any transaction Tj
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 27/65
 that is dependent on Ti (i.e., Tj has read data written by Ti ) is also aborted.
To achieve this, we need to place restrictions on the types of schedules permitted in the system.
“Recoverable schedules”
No committed transaction ever needs to be rolled back.
Recovery is possible
Nonrecoverable schedules should not be permitted by the DBMS
Uncommitted transaction may need to be rolled back
Cascading rollback may occur in some recoverable schedules
Cascadeless schedule
Reads only items that were written by committed
transactions.
Avoids cascading rollback
Strict schedule
Transactions can neither read nor write an item X until the
last transaction that wrote X has committed or aborted
Simpler recovery process
Restore the before image(old value)D
Cascading schedule
A schedule where transactions can read uncommitted data from other transactions.
If a transaction fails, it causes a cascade of rollbacks of other dependent transactions.
Leads to a more complex recovery process.
Recoverable schedule — if a transaction Tj reads a data item previously written by a transaction Ti ,
then the commit operation of Ti appears before the commit operation of Tj.
The following schedule is not recoverable

If T6 should abort, T7 would have read (and possibly shown to the user) an inconsistent database
state. Hence, database must ensure that schedules are recoverable.

Cascading rollback – a single transaction failure leads to a series of transaction rollbacks. Consider
the following schedule where none of the transactions has yet committed (so the schedule is
recoverable)

If T10 fails, T11 and T12 must also be rolled back.

Can lead to the undoing of a significant amount of work

Cascadeless schedules — cascading rollbacks cannot occur;

For each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the
commit operation of Ti appears before the read operation of Tj.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 28/65
 Every Cascadeless schedule is also recoverable
It is desirable to restrict the schedules to those that are cascadeless

The DBMS is used to schedule the access of data concurrently. It means that the user can access
multiple data from the database without being interfered with by each other. Transactions are used
to manage concurrency.
It is also used to satisfy ACID properties.
It is used to solve Read/Write Conflicts.
It is used to implement Recoverability, Serializability, and Cascading.
Transaction Management is also used for Concurrency Control Protocols and the Locking of data.

A non-serial schedule which is not serializable is called as a non-serializable schedule.

A non-serializable schedule is not guaranteed to produce the same effect as produced by some
serial schedule on any consistent database.

Characteristics-
Non-serializable schedules-
may or may not be consistent
may or may not be recoverable
If in a schedule, a transaction performs a dirty read operation from an uncommitted transaction and
commits before the transaction from which it has read the value then such a schedule is known as
an Irrecoverable Schedule.

T2 performs a dirty read operation.

The commit operation of T2 is delayed till T1 commits or roll backs.
T1 commits later.
T2 is now allowed to commit.
In case, T1 would have failed, T2 has a chance to recover by rolling back.
Step-01: Check whether the given schedule is conflict serializable or not.

If the given schedule is conflict serializable, then it is surely recoverable. Stop and report your
answer.

If the given schedule is not conflict serializable, then it may or may not be recoverable. Go and check
using other methods.

All conflict serializable schedules are recoverable.

All recoverable schedules may or may not be conflict serializable

Step-02: Check if there exists any dirty read operation.

(Reading from an uncommitted transaction is called as a dirty read)

If there does not exist any dirty read operation, then the schedule is surely recoverable. Stop and
report your answer.

If there exists any dirty read operation, then the schedule may or may not be recoverable.

Step-03: If there exists a dirty read operation, then follow the following steps-
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 29/65
 1. Find the order of commit transaction from the schedule.
2.Find the order of dirty read transaction from the schedule.

If both order matches then its a recoverable schedule else irrecoverable.

Check for conflict serializibilty: No (cycle exists T1 and T2)

Dirty Read : Yes (T3 to T2)
Check the sequence of commit
T1 -> T2 -> T3
Check the sequence of Dirty Read
T3 -> T2
Checking Whether a Schedule is Recoverable or Irrecoverable
Order does not match.
Hence, its not recoverable.
If in a schedule, A transaction performs a dirty read operation from an uncommitted transaction
and its commit operation is delayed till the uncommitted transaction either commits or roll backs
then such a schedule is called as a Recoverable Schedule.

This is a Recoverable Schedule

T1 commits before T2,
That makes the value read by T2 correct.
If in a schedule, failure of one transaction causes several other dependent transactions to rollback
or abort, then such a schedule is called as a Cascading Schedule or Cascading Rollback or Cascading
Abort.If in a schedule, failure of one transaction causes several other dependent transactions to
rollback or abort, then such a schedule is called as a Cascading Schedule or Cascading Rollback or
Cascading Abort.
If in a schedule, failure of one transaction causes several other dependent transactions to rollback
or abort, then such a schedule is called as a Cascading Schedule or Cascading Rollback or Cascading
Abort. It simply leads to the wastage of CPU time.
If in a schedule, a transaction is not allowed to read a data item until the last transaction that has
written it is committed or aborted, then such a schedule is called as a Cascadeless Schedule.
Cascadeless schedule allows only committed read operations.
It avoids cascading roll back and thus saves CPU time.

Example-

If in a schedule, a transaction is not allowed to read a data item until the last transaction that has
written it is committed or aborted, then such a schedule is called as a Cascadeless Schedule.
Cascadeless schedule allows only committed read operations.
It avoids cascading roll back and thus saves CPU time.

Example-

Cascadeless schedule allows only committed read operations.

However, it allows uncommitted write operations.

Example-
If in a schedule, a transaction is neither allowed to read nor write a data item until the last
transaction that has written is committed or aborted, then such a schedule is called as a Strict
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 30/65
 Schedule.

Strict schedule allows only committed read and write operations.

Strict schedule implements more restrictions than cascadeless schedule.

Transaction Isolation and Atomicity

Recoverable Schedule

Definition: A schedule is recoverable if for any transaction Tj that reads data written by Ti , Ti
​ ​ ​

commits before Tj commits.

​

Why Important? Ensures that if a transaction Ti fails, dependent transactions Tj can be rolled
​ ​

back to maintain consistency.

Characteristics:

1. No Dirty Reads: Only committed data is used.

2. Prevent Data Loss: Ensures that uncommitted data changes are not propagated.
3. Drawback: May still result in cascading rollbacks.

Cascading Rollback

Definition: Occurs when one transaction's failure causes a chain of rollbacks for other dependent
transactions.
Why Problematic?
Can lead to significant work loss.
Complex recovery processes.
Example:
T1 writes a value, T2 reads it, and T1 fails. T2 must roll back.
​ ​ ​ ​

Chain: If T3 depends on T2 , it must roll back too.

​ ​

Cascadeless Schedule

Definition: A schedule where a transaction can only read committed data, preventing cascading
rollbacks.
Key Characteristics:
1. No Dirty Reads: Tj cannot read data written by Ti until Ti commits or aborts.
​ ​ ​

2. Efficient Recovery: Eliminates the need for cascading rollbacks.

3. Subset of Recoverable Schedules: All cascadeless schedules are recoverable.
Example:
T1 writes a value, commits, and only then T2 reads it.
​ ​

Advantage: Prevents work loss and simplifies recovery.

Strict Schedule

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 31/65
 Definition: A stricter version of cascadeless schedules. Transactions cannot read or write a data
item until the last transaction that wrote it has committed or aborted.
Key Characteristics:
1. Prevents both dirty reads and dirty writes.
2. Ensures atomicity.
3. Simplifies recovery: Only the before image (old value) needs to be restored.
Example:
T1 writes a value and commits. Only then can T2 read or write it.
​ ​

Schedule Analysis

Recoverable vs Non-Recoverable Schedules

A recoverable schedule ensures that no committed transaction needs to be rolled back.

A non-recoverable schedule occurs when:
1. Tj commits after reading a value written by Ti .
​ ​

2. Ti fails, making Tj 's commit invalid.

​ ​

Cascading Rollbacks

Occurs in recoverable schedules where dirty reads are allowed.

Can lead to a chain reaction of rollbacks.

Cascadeless Schedules

Desirable because they:

1. Prevent cascading rollbacks.
2. Allow only committed reads.

Strict Schedules

Most restrictive but ensure both atomicity and isolation.

Prevent both dirty reads and dirty writes.

Checking Schedules for Recoverability

1. Step 1: Conflict Serializability

If a schedule is conflict serializable, it is recoverable.
2. Step 2: Check for Dirty Reads
If there are no dirty reads, the schedule is recoverable.
If dirty reads exist, proceed to step 3.
3. Step 3: Order of Commit and Dirty Read Transactions
Compare the commit order of transactions with the order of dirty reads.
If the commit order aligns with the dependency order, the schedule is recoverable.

Examples
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 32/65
Irrecoverable Schedule

T2 reads uncommitted data from T1 .

​ ​

T1 fails, but T2 has already committed → Irrecoverable.

​ ​

Recoverable Schedule

T2 reads uncommitted data from T1 , but T2 's commit is delayed until T1 commits → Recoverable.
​ ​ ​ ​

Cascading Rollback Example

T1 writes a value, T2 reads it, T3 depends on T2 .

​ ​ ​ ​

If T1 fails, both T2 and T3 must roll back.

​ ​ ​

Cascadeless Example

T2 waits for T1 to commit before reading its value → Cascadeless.

​ ​

Strict Example

T2 waits for T1 to commit before reading or writing its value → Strict Schedule.
​ ​

Summary

Recoverable Schedules: Prevent inconsistency but may cause cascading rollbacks.

Cascadeless Schedules: Prevent cascading rollbacks but allow uncommitted writes.
Strict Schedules: Prevent both dirty reads and writes, ensuring simpler recovery.

Uploaded image
explain this in detailed

The image describes variations of the Two-Phase Locking (2PL) protocol, which is used in databases
to ensure serializability and consistency in concurrent transactions. Let me break down each variation in
detail:

Basic 2PL

How It Works:
Transactions acquire locks (shared or exclusive) incrementally on data items as needed during
execution.
Once a transaction releases a lock, it cannot acquire any more locks. This is what defines the
"two phases":
Growing Phase: Locks are acquired but not released.
Shrinking Phase: Locks are released, but no new locks can be acquired.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 33/65
 Drawback:
This approach can lead to deadlocks. For example:
Transaction T1 locks data item A and waits for data item B , while transaction T2 locks
​ ​

B and waits for A, creating a circular wait.

Conservative 2PL

How It Works:
All locks required by the transaction are acquired at the start (before execution begins).
If any lock cannot be acquired, the transaction does not proceed and waits until all locks are
available.
Advantage:
Deadlock Prevention: Since all locks are acquired upfront, no circular waits can occur.
Drawback:
It requires knowing in advance which data items the transaction will access. This is not
always practical or possible in dynamic scenarios.

Strict 2PL

How It Works:
A transaction does not release any of its exclusive (write) locks until it commits or aborts.
Shared (read) locks can still be released before the transaction ends.
Advantage:
Ensures cascadeless schedules, as no other transaction can read or write the data modified
by a transaction until the modifying transaction is finished (committed or aborted).
Use Case:
Widely used in databases since it simplifies recovery mechanisms:
Only committed changes are visible.
Rollbacks are straightforward.

Rigorous 2PL

How It Works:
A transaction does not release any of its locks (shared or exclusive) until it commits or
aborts.
Advantage:
This is stricter than Strict 2PL because:
It blocks both reads and writes on a locked data item until the transaction finishes.
Ensures serializability and simplifies recovery even further, as no intermediate states are
visible to other transactions.
Drawback:
Can lead to higher contention because transactions hold locks longer, which may reduce
concurrency.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 34/65
Summary of Differences:

Feature Basic 2PL Conservative 2PL Strict 2PL Rigorous 2PL

All at once (before
Lock Acquisition Incremental Incremental Incremental
start)
Can be early Can be early Exclusive locks at All locks at
Lock Release
(shrinking) (shrinking) commit commit

Deadlock
No Yes No No
Prevention
Cascading
Possible Possible Prevented Prevented
Rollbacks
Concurrency High Moderate Low Lowest

Each variation balances trade-offs between deadlock prevention, cascading rollback prevention, and
transaction concurrency.

Uploaded image
explain this . also advantages and d

The image describes two deadlock prevention schemes in database systems: Wait-Die and Wound-
Wait. These schemes use timestamps to avoid circular waits and resolve conflicts when two
transactions contend for the same resource. Let me explain both in detail.

Wait-Die Scheme

How it works:
Each transaction Ti gets a timestamp TS(Ti ) when it starts. This timestamp indicates its
​ ​

"age" (smaller timestamp = older transaction).

If Ti tries to lock an item X that is already held by another transaction Tj :
​ ​

If TS(Ti ) < TS(Tj ) (i.e., Ti is older):

​ ​ ​

Ti is allowed to wait.
​

If TS(Ti ) > TS(Tj ) (i.e., Ti is younger):

​ ​ ​

Ti "dies" (is aborted) and is restarted later with the same timestamp.
​

Rationale:
Older transactions are given priority, so they are allowed to wait.
Younger transactions are aborted to avoid a deadlock situation.

Wound-Wait Scheme

How it works:
Again, each transaction Ti gets a timestamp TS(Ti ).
​ ​

If Ti tries to lock an item X that is already held by Tj :

​ ​

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 35/65
 If TS(Ti ) < TS(Tj ) (i.e., Ti is older):
​ ​ ​

Ti "wounds" Tj (aborts Tj ), and Tj is restarted later with the same timestamp.

​ ​ ​ ​

If TS(Ti ) > TS(Tj ) (i.e., Ti is younger):

​ ​ ​

Ti is allowed to wait.
​

Rationale:
Older transactions have the authority to abort younger ones to proceed without delay.
Younger transactions wait instead of aborting when blocked by older ones.

Advantages and Disadvantages

Feature Wait-Die Wound-Wait

Prevents deadlocks by ensuring a
Deadlock Prevents deadlocks by allowing older
consistent timestamp-based priority
Prevention transactions to preempt younger ones.
scheme.

Transaction Favors older transactions by allowing Favors older transactions by allowing them
Priority them to wait. to abort younger transactions.
May be seen as unfair to younger
More fair since younger transactions are only
Fairness transactions as they are frequently
aborted if blocked by older transactions.
aborted.
May lead to higher abort rates for younger
Performance Lower abort rates compared to Wait-Die.
transactions, causing overhead.
Possible for younger transactions if they Less chance of starvation, as transactions
Starvation
are continually restarted. retain their original timestamps on restart.

Key Differences

1. Conflict Resolution:
In Wait-Die, younger transactions abort themselves.
In Wound-Wait, older transactions force younger ones to abort.
2. Waiting:
Older transactions wait in Wait-Die.
Younger transactions wait in Wound-Wait.
3. Abort Frequency:
Higher for younger transactions in Wait-Die.
Controlled by older transactions in Wound-Wait.

Which One to Choose?

Wait-Die is simpler but can lead to more frequent aborts, especially if the system has many
younger transactions.
Wound-Wait is more aggressive but generally performs better in high-contention scenarios
because it reduces waiting times for older transactions.

By implementing either of these schemes, databases can prevent deadlocks and ensure fairness
between competing transactions.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 36/65
 Deadlocks can be described precisely in terms of a directed graph called a wait-for graph.
This graph consists of a pair G = (V , E), where V is a set of vertices and E is a set of edges.
The set of vertices consists of all the transactions in the system. Each element in the set E of edges is
an ordered pair Ti → Tj.
If Ti → Tj is in E, then there is a directed edge from transaction Ti to Tj, implying that transaction Ti is
waiting for transaction Tj to release a data item that it needs.

Transaction T17 is waiting for transactions T18 and T19.

Transaction T19 is waiting for transaction T18.
Transaction T18 is waiting for transaction T20.
Lock timeouts

In this approach, a transaction that has requested a lock waits for at most a specified amount of
time.

If the lock has not been granted within that time, the transaction is said to time out, and it rolls
itself back and restarts.

If there was in fact a deadlock, one or more transactions involved in the deadlock will time out and
roll back, allowing the others to proceed.

Too long a wait results in unnecessary delays once a deadlock has occurred. Too short a wait results
in transaction rollback even when there is no deadlock, leading to wasted resources.

Starvation is also a possibility with this sche

Since the graph does not contain any cycles, there is
no deadlocks

An algorithm that examines the state of the system is invoked periodically to determine whether a
deadlock has occurred. If one has, then the system must attempt to recover from the deadlock. To
do so, the system must:
Maintain information about the current allocation of data items to transactions, as well as any
outstanding data item requests.
Provide an algorithm that uses this information to determine whether the system has entered a
deadlock state.
Recover from the deadlock when the detect.

The following graph shows : T18 → T20 → T19 → T18.

There is a cycle present.
Hence there is a deadlock.

If deadlocks occur frequently, then the detection algorithm should be invoked more frequently.
Data items allocated to deadlocked transactions will be unavailable to other transactions until the
deadlock can be broken.
In addition, the number of cycles in the graph may also grow. In the worst case, we would invoke
the detection algorithm every time a request for allocation and that could not be granted
immediately.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 37/65
 Illustrating the deadlock problem. (a) A partial schedule of T1′ and T2′ that is in a state of deadlock.
(b) A wait-for graph for the partial schedule in (a).
On detection of deadlock, three actions have to be taken :
Select victim
Select that transaction as victim that will incur minimum cost when rollbacked.
Many factors may determine the cost of a rollback, including:
How long the transaction has computed, and how much longer the transaction will compute before
it completes its designated task.
How many data items the transaction has used.
How many more data items the transaction needs for it to complete.
How many transactions will be involved in the rollback.
Rollbock
Total rollback: Abort the transaction and then restart it.
Partial rollback: Roll back victim transaction only as far as necessary to release locks that another
transaction in cycle is waiting for.
Starvation
Oldest transaction in the deadlock set is never chosen as victim.
The image presents a problem related to database transactions and the two-phase locking (2PL)
protocol. Here’s a detailed explanation of the problem and solution:

Problem
We have two transactions,
𝑇
34
and
𝑇
35
, with the following operations:

Transaction
𝑇
34
:
read(A);
read(B);
if A = 0 then B := B + 1;
write(B).
Transaction
𝑇
35
:
read(B);
read(A);
if B = 0 then A := A + 1;
write(A).
The task is to add lock and unlock instructions to these transactions to ensure they follow the two-
phase locking protocol and to determine if the execution can result in a deadlock.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 38/65
 Two-Phase Locking Protocol (2PL)
The two-phase locking protocol requires that all locking operations (lock requests) precede the first
unlock operation. This ensures serializability but can lead to deadlocks.

Solution
We need to introduce lock and unlock instructions to both transactions. Here’s how you can do it:

Modified Transaction
𝑇
34
:
lock(A);
read(A);
lock(B);
read(B);
if A = 0 then B := B + 1;
write(B);
unlock(B);
unlock(A);
Modified Transaction
𝑇
35
:
lock(B);
read(B);
lock(A);
read(A);
if B = 0 then A := A + 1;
write(A);
unlock(A);
unlock(B);
Deadlock Analysis
To determine if these transactions can lead to a deadlock, consider the following scenario:

𝑇
34
locks
𝐴
and
𝑇
35
locks
𝐵
.

𝑇
34
requests a lock on
𝐵
, but it’s already locked by
𝑇
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 39/65
 35
.

𝑇
35
requests a lock on
𝐴
, but it’s already locked by
𝑇
34
.

This leads to a deadlock because both transactions are waiting for each other to release the locks
they hold, and neither can proceed.

explain this in detailed

Certainly! Let's delve deeper into the concepts and details of the transactions and the two-phase
locking (2PL) protocol as depicted in the image.

Transactions and Operations

Transaction
𝑇
34
:
lock-S(A) - Acquire a shared lock on resource
𝐴
.

read(A) - Read the value of

𝐴
.

lock-X(B) - Acquire an exclusive lock on resource

𝐵
.

read(B) - Read the value of

𝐵
.

if A = 0 - Check if the value of

𝐴
is zero.

then B := B + 1 - If
𝐴
is zero, increment the value of
𝐵
by 1.

write(B) - Write the updated value of

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 40/65
 𝐵
.

unlock(A) - Release the shared lock on resource

𝐴
.

unlock(B) - Release the exclusive lock on resource

𝐵
.

Transaction
𝑇
35
:
lock-S(B) - Acquire a shared lock on resource
𝐵
.

read(B) - Read the value of

𝐵
.

lock-X(A) - Acquire an exclusive lock on resource

𝐴
.

read(A) - Read the value of

𝐴
.

if B = 0 - Check if the value of

𝐵
is zero.

then A := A + 1 - If
𝐵
is zero, increment the value of
𝐴
by 1.

write(A) - Write the updated value of

𝐴
.

unlock(B) - Release the shared lock on resource

𝐵
.

unlock(A) - Release the exclusive lock on resource

𝐴
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 41/65
 .

Detailed Explanation
Two-Phase Locking (2PL) Protocol
The 2PL protocol ensures serializability in database transactions by dividing the execution of a
transaction into two phases:

Growing Phase: The transaction can acquire locks but cannot release any locks.

Shrinking Phase: The transaction can release locks but cannot acquire any new locks.

This ensures that once a transaction releases a lock, it cannot obtain any new locks, preventing it
from causing inconsistencies.

Transaction
𝑇
34
:
lock-S(A): This instruction acquires a shared lock on
𝐴
, allowing
𝑇
34
to read
𝐴
but not modify it. Other transactions can also read
𝐴
but cannot modify it until the lock is released.

read(A): Reads the current value of

𝐴
.

lock-X(B): Acquires an exclusive lock on

𝐵
, allowing
𝑇
34
to both read and modify
𝐵
. No other transaction can access
𝐵
until the lock is released.

read(B): Reads the current value of

𝐵
.

Condition Check: Checks if

𝐴
is equal to 0.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 42/65
 Update
𝐵
: If
𝐴
is zero, increments the value of
𝐵
by 1.

write(B): Writes the updated value to

𝐵
.

unlock(A): Releases the shared lock on

𝐴
.

unlock(B): Releases the exclusive lock on

𝐵
.

Transaction
𝑇
35
:
lock-S(B): This instruction acquires a shared lock on
𝐵
, allowing
𝑇
35
to read
𝐵
but not modify it. Other transactions can also read
𝐵
but cannot modify it until the lock is released.

read(B): Reads the current value of

𝐵
.

lock-X(A): Acquires an exclusive lock on

𝐴
, allowing
𝑇
35
to both read and modify
𝐴
. No other transaction can access
𝐴
until the lock is released.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 43/65
 read(A): Reads the current value of
𝐴
.

Condition Check: Checks if

𝐵
is equal to 0.

Update
𝐴
: If
𝐵
is zero, increments the value of
𝐴
by 1.

write(A): Writes the updated value to

𝐴
.

unlock(B): Releases the shared lock on

𝐵
.

unlock(A): Releases the exclusive lock on

𝐴
.

Deadlock Potential
Deadlock: A situation where two or more transactions are waiting for each other to release locks,
creating a cycle of dependencies with no resolution.

Scenario Leading to Deadlock:

𝑇
34
acquires a shared lock on
𝐴
.

𝑇
35
acquires a shared lock on
𝐵
.

𝑇
34
tries to acquire an exclusive lock on
𝐵
, but
𝐵
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 44/65
 is already locked by
𝑇
35
.

𝑇
35
tries to acquire an exclusive lock on
𝐴
, but
𝐴
is already locked by
𝑇
34
.

Both transactions are now waiting for each other to release their respective locks, resulting in a
deadlock. Neither transaction can proceed, and the system must intervene to break the deadlock,
typically by aborting and restarting one of the transactions.

Summary
Transactions
𝑇
34
and
𝑇
35
are designed to read and modify shared resources
𝐴
and
𝐵
.

2PL Protocol: Ensures serializability by dividing the transaction into a growing phase (acquiring
locks) and a shrinking phase (releasing locks).

Deadlock Potential: Occurs when transactions .

Now give through each and every word and understand the topic and explain each and every line
wtith examples tooo.

Sure! Let's break down each line and concept related to deadlocks, two-phase locking protocol (2PL),
and the wait-for graph in detail with examples.

Deadlocks in Transactions

Line 1: Deadlocks can be described precisely in terms of a directed graph called a wait-for graph.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 45/65
 Explanation: A deadlock occurs when two or more transactions are waiting for each other to
release resources (locks), creating a cycle of dependency. This scenario is modeled using a wait-for
graph.
Example: If Transaction T 1 is waiting for a lock held by T 2, and T 2 is waiting for a lock held by T 1
, we can represent this situation as a graph:
Vertices (V ): Transactions T 1, T 2
Edges (E ): T 1 → T 2, T 2 → T 1

Line 2: This graph consists of a pair G = (V , E), where V is a set of vertices and E is a set of edges.

Explanation:
V : Represents all active transactions.
E : Represents dependencies, where T i → T j means T i is waiting for T j to release a lock.
Example: If three transactions T 1, T 2, T 3 have the following dependencies:
T 1 waits for T 2
T 2 waits for T 3
T 3 waits for T 1, the wait-for graph will have a cycle: T 1 → T 2 → T 3 → T 1, indicating a
deadlock.

Line 3: The set of vertices consists of all the transactions in the system.

Explanation: Each transaction is represented as a node in the graph.

Example:
Transactions: T 1, T 2, T 3
Vertices in the graph: V = {T 1, T 2, T 3}

Line 4: Each element in the set E of edges is an ordered pair T i → T j.

Explanation: An edge T i → T j means T i is waiting for T j to release a resource.

Example:
T 1 is waiting for a lock held by T 2.
Edge in the graph: T 1 → T 2.

→ T j is in E , then there is a directed edge from transaction T i to T j , implying that

Line 5: If T i
transaction T i is waiting for transaction T j to release a data item that it needs.

Explanation: The direction of the edge shows which transaction is waiting for another.
Example:
T 3 is waiting for T 4 to release a resource.
In the graph, draw a directed edge T 3 → T 4.

Scenario Analysis

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 46/65
Transaction T 17 is waiting for T 18 and T 19.

Transaction T 19 is waiting for T 18.

Transaction T 18 is waiting for T 20.

Graph Representation:
T 17 → T 18
T 17 → T 19
T 19 → T 18
T 18 → T 20
Cycle Check: This graph has no cycles; hence, there is no deadlock.

Deadlock Detection and Recovery

Line 6: In this approach, a transaction that has requested a lock waits for at most a specified amount
of time.

Explanation: To prevent indefinite waiting, a timeout mechanism is used. If the transaction does
not get the lock within a certain time, it times out, rolls back, and restarts.

Line 7: If the lock has not been granted within that time, the transaction is said to time out, and it rolls
itself back and restarts.

Example:
T 1 requests a lock on A, which is held by T 2.
If T 2 does not release the lock within 5 seconds, T 1 times out, releases any locks it holds,
rolls back its changes, and restarts.

Line 8: If there was in fact a deadlock, one or more transactions involved in the deadlock will time out
and roll back, allowing the others to proceed.

Explanation: Timeout helps break deadlocks by forcing one or more transactions to release locks
and roll back.
Example:
T 1 and T 2 are in a deadlock. T 1 times out, releasing its locks. This allows T 2 to proceed.

Deadlock Detection Algorithm

Line 9: An algorithm that examines the state of the system is invoked periodically to determine
whether a deadlock has occurred.

Explanation: The system checks for cycles in the wait-for graph.

Example:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 47/65
 Wait-for graph: T 1→ T2 → T3 → T1
The cycle T 1 → T 2 → T 3 → T 1 indicates a deadlock.

Line 10: To recover from the deadlock, the system must:

1. Select a Victim:
Choose a transaction to abort, minimizing rollback cost.
2. Rollback:
Either completely abort the victim or roll it back partially to release locks.
3. Starvation Prevention:
Ensure the same transaction is not always selected as the victim.

Two-Phase Locking Protocol (2PL)

Modified Transactions

Transaction T 34:

plaintext

lock(A); // Acquire a lock on A

read(A); // Read value of A
lock(B); // Acquire a lock on B
read(B); // Read value of B
if (A == 0)
B := B + 1;
write(B); // Update B
unlock(B); // Release lock on B
unlock(A); // Release lock on A

Transaction T 35:

plaintext

lock(B); // Acquire a lock on B

read(B); // Read value of B
lock(A); // Acquire a lock on A
read(A); // Read value of A
if (B == 0)
A := A + 1;
write(A); // Update A
unlock(A); // Release lock on A
unlock(B); // Release lock on B

Deadlock Analysis

1. Scenario:
T 34: Locks A, then tries to lock B .
T 35: Locks B , then tries to lock A.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 48/65
 2. Deadlock:
T 34: Waits for B (held by T 35).
T 35: Waits for A (held by T 34).
Cycle: T 34 → T 35 → T 34

Summary

Deadlock occurs when transactions are in a circular wait, as represented in a wait-for graph.
Two-phase locking (2PL) ensures serializability but may lead to deadlocks.
Deadlock detection involves cycle detection in the graph.
Recovery involves selecting a victim transaction to abort or roll back to break the cycle.

explain about timeout topic

Timeout Mechanism in Deadlock Handling

Timeout is a strategy used in database systems to deal with deadlocks by allowing transactions to wait
only for a limited period of time before aborting and rolling back. The goal of this mechanism is to
prevent indefinite waiting and to recover resources that might otherwise remain locked due to a
deadlock.

Explanation

1. Definition
A timeout mechanism specifies a maximum amount of time that a transaction is allowed to wait for
a lock to be granted. If the lock is not granted within this time, the transaction is rolled back and
restarted.
This avoids deadlock situations where multiple transactions wait indefinitely for each other to
release resources.

Steps in Timeout Mechanism

1. Request for a Lock:

A transaction requests a lock on a data item that is currently held by another transaction.
2. Waiting Period:
The transaction waits for a specific period (timeout period) for the lock to be granted.
3. Timeout Detection:
If the lock is granted within the timeout period, the transaction proceeds normally.
If the lock is not granted within the timeout period, the transaction is aborted and
restarted.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 49/65
 4. Rollback and Restart:
When a timeout occurs, the transaction is rolled back (undoing any changes it might have made so
far) and then restarted to retry its operations.

Example

Scenario:

Transaction T1: Holds a lock on data item `A` and requests a lock on data item `B`.
Transaction T2: Holds a lock on data item `B` and requests a lock on data item `A`.

Without Timeout:

Both transactions wait indefinitely for each other to release the locks, leading to a deadlock.

With Timeout:

Suppose `T1` has a timeout period of 5 seconds.

If `T1` cannot acquire the lock on `B` within 5 seconds, it times out, rolls back, and releases the
lock on `A`.
This allows `T2` to acquire the lock on `A` and proceed, breaking the deadlock.

Advantages of Timeout Mechanism

1. Simplicity:
Timeout is relatively simple to implement compared to more complex deadlock detection and
recovery techniques.
2. Automatic Recovery:
Transactions that time out are rolled back automatically, allowing other transactions to
proceed.
3. Prevents Indefinite Waiting:
By limiting the wait time, the system avoids scenarios where transactions wait forever for
resources.

Disadvantages of Timeout Mechanism

1. Unnecessary Rollbacks:
If a transaction times out and rolls back when there is no deadlock, it results in wasted
resources and reduced throughput.
Example:
If `T1` times out even though `T2` was just about to release the lock, the rollback is
unnecessary and wasteful.
2. Performance Impact:
Frequent timeouts and rollbacks can degrade the overall performance of the system,
especially under high transaction loads.
3. Starvation:
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 50/65
 A transaction may repeatedly time out and restart without completing its task, especially if it
competes with higher-priority or long-running transactions. This leads to starvation.

Balancing Timeout Period

The timeout period plays a critical role in the effectiveness of this approach:

Too Long:
Deadlocks may persist unnecessarily, causing delays in the system.
Transactions might waste time waiting when they could have been restarted earlier.
Too Short:
Transactions may time out and restart even when no deadlock exists, causing unnecessary
rollbacks and wasted resources.

Example:

If the timeout period is only 1 second, a transaction holding a lock for legitimate reasons might
cause multiple other transactions to time out unnecessarily.

Comparison with Other Deadlock Handling Techniques

Aspect Timeout Deadlock Detection and Recovery

Complexity Simple to implement Requires periodic deadlock detection
Overhead Minimal Higher due to graph or cycle checks
Effectiveness Works well for infrequent deadlocks Suitable for frequent deadlocks
Risk of Starvation High (with short timeouts) Low (with proper victim selection)

Conclusion

The timeout mechanism is a simple yet effective method for handling deadlocks in database systems.
However, it needs careful tuning of the timeout period to strike a balance between avoiding
unnecessary rollbacks and minimizing deadlock durations. For systems with frequent or complex
deadlocks, timeout alone may not be sufficient, and more sophisticated techniques like deadlock
detection and prevention might be required.

explain starvation part

Starvation in Databases

Starvation occurs when a transaction or process is perpetually denied access to the resources it needs
to proceed, often because other transactions or processes are given higher priority or dominate the
system’s resources.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 51/65
In the context of database systems, starvation is a significant issue when resource allocation or
concurrency control mechanisms unfairly block certain transactions.

How Starvation Occurs

Starvation typically arises in scenarios involving:

1. Priority-Based Scheduling:
Some transactions have higher priorities and are always executed first.
Lower-priority transactions may never get a chance to execute if high-priority transactions
keep arriving.
Example:
A system gives priority to short-running transactions over long-running ones.
A long transaction (`T1`) might wait indefinitely if shorter transactions (`T2`, `T3`, etc.)
continuously arrive.
2. Locks and Resource Contention:
A transaction may wait indefinitely to acquire a lock on a resource if other transactions keep
holding or requesting the resource.
Example:
Transaction `T1` requests a lock on resource `R1`, but higher-priority transactions or frequent
timeouts cause `T1` to restart repeatedly, leading to starvation.
3. Timeout Mechanism:
In systems using a timeout mechanism for deadlock handling, a transaction may timeout
repeatedly and get restarted without making progress.
Example:
Transaction `T1` keeps timing out while waiting for a resource locked by a long transaction or
frequently restarted transactions.
4. Resource Hoarding:
A few transactions monopolize system resources (like locks, CPU time, or memory), leaving
others waiting indefinitely.

Difference Between Deadlock and Starvation

Aspect Deadlock Starvation

Two or more transactions wait indefinitely for each A transaction waits indefinitely while
Definition
other, causing a complete halt. others proceed.
Cause Cyclic dependency on resources. Unfair resource allocation or scheduling.
Requires fair resource scheduling or
Resolution Requires deadlock detection, prevention, or recovery.
prioritization mechanisms.

Example of Starvation

Scenario:

Three transactions (`T1`, `T2`, `T3`) are running in a database system.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 52/65
 The system implements a priority-based lock mechanism:
`T1` has low priority.
`T2` and `T3` have higher priority.

Problem:

Every time `T1` requests a lock, the system grants the lock to `T2` or `T3` first.
If `T2` and `T3` keep requesting locks repeatedly, `T1` may never get the resources it needs to
proceed.

This indefinite delay for `T1` results in starvation.

Causes of Starvation

1. Unfair Locking Policies:

Locks are granted based on priority, and low-priority transactions are ignored.
2. Frequent Restarts (Timeout-Based Deadlock Handling):
Transactions may timeout and restart so often that they cannot complete their operations.
3. Excessive Resource Contention:
A few transactions consume most of the system's resources, leaving little for others.
4. Lack of Fairness in Scheduling:
Scheduling algorithms that favor certain types of transactions (e.g., short transactions) can
lead to prolonged delays for others.

Effects of Starvation

1. Wasted Resources:
Transactions that starve consume system resources like CPU cycles and memory without
making progress.
2. Reduced Throughput:
Prolonged waiting times for some transactions can lower the overall system throughput.
3. Unpredictable Performance:
Starvation makes the system's behavior unpredictable, especially for low-priority tasks.
4. User Dissatisfaction:
If user transactions experience delays or never complete, it can lead to poor user satisfaction.

Preventing Starvation

To avoid starvation, database systems implement mechanisms to ensure fair resource allocation and
progress for all transactions.

1. Fair Locking Policies

Use a FIFO (First-In-First-Out) queue for granting locks, ensuring that requests are served in the
order they arrive.
Avoid strict priority-based locking.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 53/65
Example:

Instead of giving priority to short-running transactions, lock requests are queued, and each
transaction gets its turn.

2. Aging Mechanism

Increase the priority of a transaction the longer it waits.

Older transactions are prioritized over newer ones, ensuring eventual execution.

Example:

A low-priority transaction’s priority increases over time until it surpasses the priority of other
transactions.

3. Deadlock-Free and Starvation-Free Algorithms

Use algorithms like the Banker’s Algorithm or fair scheduling algorithms that prevent both
deadlocks and starvation.

4. Avoid Frequent Restarts

In timeout-based deadlock handling, fine-tune the timeout duration to minimize unnecessary

rollbacks and reduce the chances of starvation.

5. Resource Limits

Set a limit on the number of resources any single transaction can hold at a time to prevent
resource hoarding.

6. Fair Scheduling Policies

Implement fair CPU scheduling mechanisms like Round-Robin Scheduling or Weighted Fair
Queuing to ensure all transactions get some execution time.

Conclusion

Starvation is a common issue in database systems, especially in environments with high contention for
resources. It can occur due to unfair priority systems, timeout mechanisms, or monopolization of
resources by a few transactions. By implementing fairness mechanisms like aging, FIFO queues, and
balanced timeout periods, database systems can effectively prevent starvation and ensure smooth
transaction processing.

TBlock movements between disk and main memory are initiated through the following two
operations:
input (B) transfers the physical block B to the main memory.
output (B) transfers the buffer block B to the disk and replaces the appropriate physical block there.
ransactions

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 54/65
 Must perform read(X) before accessing X for the first time (subsequent reads can be from local copy)

write(X) can be executed at any time before the transaction commits

We assume, for simplicity, that each data item fits in, and is stored inside a single block.
Each transaction Ti has its private work area in which local copies of all data items accessed and
updated by it are kept.
Ti's local copy of a data item X is called xi.
Transferring data items between system buffer blocks and their private work area done by:
read(X) assigns the value of data item X to the local variable xi.
write(X) assigns the value of local variable xi to data item {X} in the buffer block.
Note: output(BX) need not immediately follow write(X). The system can perform the output
operation when it deems fit.
Block movements between disk and main memory are initiated through the following two
operations:
input (B) transfers the physical block B to the main memory.
output (B) transfers the buffer block B to the disk and replaces the appropriate physical block there.

explain inndetailed

Detailed Explanation of Block Movements and Transactions

In a database system, data is stored on the disk in the form of blocks. To perform any operations on
data, such as reading or writing, the relevant block must be transferred between the disk and main
memory (RAM). This is because CPU operations can only interact with data in main memory. The system
initiates these transfers through two primary operations:

1. Block Movement Operations

a) Input(B)

Definition:
Transfers the physical block `B` from the disk to the main memory.
Purpose:
To load the block into memory so that its data can be accessed or modified.
Use Case:
When a transaction needs to access a data item stored in a block `B` for the first time during
execution.
Example:
If block `B1` contains a data item `X` and the transaction `T1` requires `X`, the database system
issues an `input(B1)` operation to bring the block into main memory.

b) Output(B)

Definition:
Transfers the buffer block `B` (a modified block in the main memory) back to the disk, replacing
the corresponding physical block on the disk.
Purpose:
To ensure that updates made to data in memory are saved permanently on disk.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 55/65
 Use Case:
After a transaction modifies a data item in block `B`, the system eventually performs an
`output(B)` to write the updated block back to disk.
Example:
If block `B1` was modified in memory (e.g., `X` was updated), `output(B1)` writes the updated
block back to the disk.

2. Transactions and Local Work Areas

A transaction is a sequence of operations (read/write) that must be executed atomically to ensure data
consistency.

Local Work Area

Each transaction maintains a private workspace in the main memory, where it keeps local copies
of data items it accesses or modifies.
Local Copy (xi):
A transaction’s private copy of a data item `X`. This allows the transaction to work on its own
version of the data without interfering with other transactions.

3. Key Operations in Transactions

a) `read(X)`

Definition:
Transfers the value of a data item `X` from the system’s buffer block (or disk) to the transaction’s
local copy (`xi`).
Steps:
1. If the block `B` containing `X` is not already in memory, perform `input(B)` to bring it into
the buffer.
2. Assign the value of `X` to the local variable `xi`.
Purpose:
To ensure the transaction can access `X` for computations.
Example:
Assume `X` is part of block `B1` on the disk.
If block `B1` is not in memory:
1. Perform `input(B1)` to load it into memory.
2. Copy the value of `X` into the transaction's workspace as `xi`.

b) `write(X)`

Definition:
Transfers the value of the transaction's local copy (`xi`) to the buffer block containing `X`.
Steps:
1. Update the value of `X` in the buffer block using `xi`.
2. The system can perform `output(B)` at a later time to save the updated block to disk.

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 56/65
 Purpose:
To modify `X` locally before committing the changes to disk.
Example:
If a transaction modifies `X` (stored in `xi`), it writes the updated value back to the buffer
block containing `X`.
The system eventually issues an `output(B)` to save the modified block to disk.

4. Rules for Transactions

To ensure consistency and correctness, transactions follow these rules:

a) `read(X)` Before Access

A transaction must perform a `read(X)` operation before accessing `X` for the first time.
This ensures that the transaction works on the most recent value of `X`.

b) `write(X)` Timing

The `write(X)` operation can be executed at any point before the transaction commits.
However, the updated value is only guaranteed to be saved permanently when the system
performs `output(B)`.

c) Block-Level Operations

Since each data item (`X`) is stored within a single block (`B`), operations on `X` are tied to
operations on `B`.

5. System Buffer and Output Delay

The buffer block in main memory plays a critical role in managing data movements:

Buffer Block:
A copy of a physical block in main memory that allows the system to temporarily hold and
manipulate data.
Output Delay:
The `output(B)` operation does not need to immediately follow a `write(X)`.
The system can defer the `output(B)` operation until it deems it necessary (e.g., when the
buffer is full or during a commit).

6. Example Workflow

Scenario:

Data Item: `X` (stored in block `B1` on disk).

Transaction: `T1` needs to update `X`.

Steps:

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 57/65
 1. Reading Data:
`T1`issues `read(X)`:
If `B1` is not in memory, the system performs `input(B1)` to load it into the buffer.
`X` is assigned to `xi` in `T1`’s local workspace.
2. Modifying Data:
`T1` updates its local copy (`xi`).
3. Writing Data:
`T1`issues `write(X)`:
The system updates the value of `X` in the buffer block `B1`.
4. Committing Changes:
The system eventually performs `output(B1)`:
The modified block `B1` is written back to disk.

7. Importance of Block Movement Mechanisms

Efficient handling of block movements is critical for database systems because:

1. Performance Optimization:
Reducing unnecessary `input(B)` and `output(B)` operations minimizes disk I/O, which is
much slower than main memory operations.
2. Concurrency Control:
Ensuring proper isolation of transactions by maintaining local copies (`xi`) prevents conflicts
between transactions.
3. Consistency and Durability:
Deferring `output(B)` until a commit ensures that the system writes only consistent data to
disk.

Conclusion

Block movement operations (`input(B)` and `output(B)`) form the foundation of data access in database
systems. By leveraging a combination of system buffers, private work areas, and deferred output,
databases ensure efficient, consistent, and concurrent transaction processing. This architecture
minimizes disk I/O and provides a structured way to manage transactions’ access to data stored on disk.

Recovery Atomicity
Recovery Algorithm
1. Recovery Atomicity
To ensure atomicity despite failures, we first output information describing the modifications to
stable storage without modifying the database itself.
We study log-based recovery mechanisms in detail
We first present key concepts
And then present the actual recovery algorithm
Less used alternatives: shadow-copy and shadow-paging (brief details in the book Database system
concepts seventh edition – page: 914)
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 58/65
 The most widely used structure for recording database modifications is the log. The log is a
sequence of log records, recording all the update activities in the database.
There are several types of log records. An update log record describes a single database write. It has
these fields:
• Transaction identifier, which is the unique identifier of the transaction that per-
formed the write operation.
• Data-item identifier, which is the unique identifier of the data item written. Typically, it is the
location on disk of the data item, consisting of the block identifier of the block on which the data
item resides and an offset within the block.
• Old value, which is the value of the data item prior to the write.
• New value, which is the value that the data item will have after the write.

We represent an update log record as <Ti, Xj, V1, V2>, indicating that transaction Ti has performed a
write on data item Xj. Xj had value V1 before the write and has value V2 after the write. Other special
log records exist to record significant events during transaction processing, such as the start of a
transaction and the commit or abort of a transaction. Among the types of log records are:
• <Ti start>. Transaction Ti has started.
• <Ti commit>. Transaction Ti has committed.
• <Ti abort>. Transaction Ti has aborted.

A log is a sequence of log records. The records keep information about updated activities on the
database.
The log is kept in stable storage
When transaction Ti starts, it registers itself by writing a <Ti start> log record
Before Ti executes write(X), a log record <T, X, V1, V2> is written, where V1 is the value of X before
the write (the old value), and V2 is the value to be written to X (the new value).
When Ti finishes its last statement, the log record <Ti commit> is written.

As we noted earlier, a transaction creates a log record prior to modifying the database.
The log records allow the system to undo changes made by a transaction in the event that the
transaction must be aborted; they allow the system also to redo changes made by a transaction if
the transaction has committed but the system crashed before those changes could be stored in the
database on disk. In order for us to understand the role of these log records in recovery, we need to
consider the steps a transaction takes in modifying a data item:
1. The transaction performs some computations in its own private part of main memory.
2. The transaction modifies the data block in the disk buffer in main memory holding the data item.
3. The database system executes the output operation that writes the data block to disk.
Two approaches using logs
Immediate database modification
Deferred database modification.

The immediate-modification scheme allows updates of an uncommitted transaction to be made to

the buffer, or the disk itself before the transaction commits
Update log record must be written before the database item is written
We assume that the log record is output directly to stable storage
(Will see later that how to postpone log record output to some extent)
Output of updated blocks to disk can take place at any time before or after the transaction commit
Order in which blocks are output can be different from the order in which they are written.
The deferred-modification scheme performs updates to buffer/disk only at the time of transaction
commit
Simplifies some aspects of recovery
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 59/65
 But has overhead of storing a local copy
Log
<T0 start>
<T0, A, 1000, 950>
<T0, B, 2000, 2050>
<T0 commit>
<T1 start>
<T1, C, 700, 600>
<T1 commit>
Write
A = 950
B = 2050
C = 600
Output
BB, BC
BA
Note
BX denotes block containing X.
Description
The image shows a log of transactions and their corresponding writes and outputs in a database
system. The log records the start and commit points of transactions
𝑇
0
and
𝑇
1
, as well as the changes made to variables
𝐴
,
𝐵
, and
𝐶
. The write section shows the final values of these variables after the transactions. The output
section indicates the order in which the blocks containing these variables are outputted, with
specific notes on the timing of these outputs relative to the commits of the transactions. This is
relevant for understanding the sequence of operations and the consistency of the database
state.Recovery actions in each case above are:
(a) undo (T0): B is restored to 2000 and A to 1000, and log records <T0, B, 2000>, <T0, A, 1000>, <T0,
abort> are written out
(b) redo (T0) and undo (T1): A and B are set to 950 and 2050 and C is restored to 700. Log records
<T1, C, 700>, <T1, abort> are written out.
(c) redo (T0) and redo (T1): A and B are set to 950 and 2050 respectively. Then C is set to 600

When a system crash occurs, we must consult the log to determine those transactions that need to
be redone and those that need to be undone. In principle, we need to search the entire log to
determine this information. There are two major difficulties with this approach:
1. The search process is time-consuming.
2. Most of the transactions that, according to our algorithm, need to be redone have
already written their updates into the database. Although redoing them will cause no harm, it will
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 60/65
 nevertheless cause recovery to take longer.
To reduce these types of overhead, we introduce checkpoints.
Streamline recovery procedure by periodically performing checkpointing
Output all log records currently residing in main memory onto stable storage.
Output all modified buffer blocks to the disk.
Write a log record < checkpoint L> onto stable storage where L is a list of all transactions active at
the time of checkpoint.
All updates are stopped while doing checkpointing
During recovery we need to consider only the most recent transaction Ti that started before the
checkpoint and transactions that started after Ti.
Scan backward from end of the log to find the most recent <checkpoint L> record

Only transactions that are in L or started after the checkpoint need to be redone or undone
Transactions that committed or aborted before the checkpoint already have all their updates output
to stable storage.
Some earlier part of the log may be needed for undo operations
Continue scanning backwards till a record <Ti start> is found for every transaction Ti in L.
Parts of the log prior to the earliest <Ti start> record above are not needed for recovery and can be
erased whenever desired.
The requirement that transactions must not perform any updates to buffer blocks or to the log
during checkpointing can be bothersome, since transaction processing has to halt while a
checkpoint is in progress. A fuzzy checkpoint is a checkpoint where transactions are allowed to
perform updates even while buffer blocks are being written out.
T1 can be ignored (updates already output to disk due to checkpoint)
T2 and T3 redone.
T4 undone
explain the above each and every concept in detailed

Let me break down the concepts of Recovery Atomicity and the Recovery Algorithm into detailed
explanations for each aspect mentioned.

1. Recovery Atomicity
Definition

Recovery atomicity ensures that a transaction is either fully completed (all its operations are
executed) or fully undone (no partial effects remain) in case of failures such as system crashes.

Key Idea

Before modifying the database directly, information about modifications is logged to stable storage.
This ensures that, in case of a failure:

The system can undo or redo changes to maintain the database's consistency and atomicity.

Log-Based Recovery
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 61/65
 Log: A sequence of records written to stable storage, detailing all updates and key transaction
events (start, commit, or abort).
Types of log records:
1. Transaction Start: `<Ti start>` indicates the beginning of transaction Ti .
​

2. Transaction Commit: `<Ti commit>` indicates that Ti has successfully completed.

​

3. Transaction Abort: `<Ti abort>` indicates Ti was terminated and rolled back.
​

4. Update Record: `<Ti, Xj, V1, V2>` describes a write operation by Ti on data item Xj ,
​ ​

where:
V 1: Old value before the write.
V 2: New value after the write.

2. Steps in a Transaction’s Modification

When a transaction modifies a data item, the process involves three major steps:

1. Computation in Private Memory

A transaction computes locally and works with its own private copy of the data.
2. Buffer Modification
The transaction modifies the data block in the buffer residing in main memory.
These changes are not yet reflected on the disk.
3. Disk Output
The database system eventually writes the modified block from the buffer to the disk.

3. Log-Based Recovery Mechanisms

Two main schemes define when and how the modifications to the database are made:

A. Immediate Database Modification

Definition: Updates by a transaction can be applied to the buffer or the disk before the
transaction commits.
Key Points:
Update log records must be written to stable storage before the database is modified.
The output of updated blocks to the disk can happen:
Before the transaction commits.
After the transaction commits.
The order of writing log records and data to disk can differ.

Example of Recovery Actions:

Undo operations use the "old value" (V 1) in the log to reverse uncommitted changes.
Redo operations use the "new value" (V 2) in the log to apply changes from committed
transactions.

B. Deferred Database Modification

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 62/65
 Definition: Updates by a transaction are written to the buffer/disk only at the time of commit.
Key Points:
Simplifies recovery as no undo operations are required (uncommitted transactions never
modify the database).
All updates are applied in bulk at commit time, causing higher memory overhead (local copies
are maintained until the commit).

Example of Recovery Actions:

Only redo operations are needed since no changes are made to the database until the transaction
commits.

4. Transaction Log Example

Here’s an example log with recovery actions for different cases:

Log Structure

plaintext

Log:
<T0 start>
<T0, A, 1000, 950>
<T0, B, 2000, 2050>
<T0 commit>
<T1 start>
<T1, C, 700, 600>
<T1 commit>

Write:
A = 950, B = 2050, C = 600

Output (disk):
Block_B, Block_C
Block_A

Recovery Scenarios

1. Case (a): Undo T 0

T 0 is uncommitted.
Restore A to 1000 and B to 2000.
Log additional undo records:

plaintext

<T0, A, 1000>
<T0, B, 2000>
<T0 abort>

2. Case (b): Redo T 0, Undo T 1

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 63/65
 T 0 committed but T 1 aborted.
Set A = 950, B = 2050, undo C to 700.
Log additional undo record:

plaintext

<T1, C, 700>
<T1 abort>

3. Case (c): Redo T 0 and T 1

Both transactions committed.

Apply all writes:
A = 950, B = 2050, C = 600.

5. Checkpointing
Purpose

To streamline recovery and reduce the amount of log data scanned after a crash.

Process

1. Output all log records in memory to stable storage.

2. Write all modified buffer blocks to the disk.
3. Write a checkpoint record `<checkpoint L>` to the log, where L is the list of active transactions.

Recovery Steps After Checkpoint

1. Scan backward from the end of the log to the most recent `<checkpoint L>`.
2. Consider only transactions in L or those started after the checkpoint for redo/undo operations.
3. Ignore earlier transactions (their updates are already stable).

Fuzzy Checkpoints

Allow updates during checkpointing to reduce transaction delays.

However, some additional complexities arise during recovery.

Summary

1. Recovery Atomicity ensures all-or-nothing transaction execution using logs.

2. Logs capture:
Start/commit/abort records for transactions.
Update records to allow undo and redo actions.
3. Immediate vs. Deferred Modifications:
Immediate: Updates can happen before commit (requires undo/redo during recovery).
Deferred: Updates only happen at commit (requires only redo during recovery).
4. Checkpoints optimize recovery by reducing log scanning.
5. Recovery actions depend on transaction states (committed or uncommitted).

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 64/65
Let me know if you'd like more elaboration on any specific part!

Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 65/65