Chapter 3: Transaction concepts

Transaction processing is a fundamental concept in database management systems that ensures

accurate and reliable processing of a series of operations or commands executed on a database.
Transactions are logically grouped operations that can be either fully completed (committed) or
fully undone (rolled back) in case of failure.

Key concepts in transaction processing include:

1. ACID Properties

ACID stands for Atomicity, Consistency, Isolation, and Durability. These properties ensure that
transactions are processed reliably.

 Atomicity: Ensures that all operations within a transaction are completed. If any
operation fails, the entire transaction fails, and the database state is unchanged.
o Example: If a bank transfer involves deducting money from one account and
adding it to another, if the deduction succeeds but the addition fails, both
operations must roll back to ensure money is not lost.
 Consistency: Ensures that a transaction brings the database from one valid state to
another without violating any integrity constraints.
o Example: If a transaction updates a student’s grade in a grading system, the grade
must be consistent with the overall grading policy (like not allowing scores to
exceed a certain maximum).
 Isolation: Ensures that transactions are executed in isolation from one another.
Concurrent transactions should not interfere with each other.
o Example: If two transactions are trying to update the account balance of the same
bank account simultaneously, isolation ensures that one transaction completes
before the other starts, preventing incorrect balances from being reflected.
 Durability: Ensures that once a transaction has been committed, it will remain persistent,
even in the event of a system failure.
o Example: When a transaction that updates the inventory count is committed, that
change will not be lost even if the system crashes immediately afterward.

2. Transaction States

Transactions can be in various states during their lifecycle:

 Active: The initial state when the transaction is being executed.

 Partially Committed: The state after the final statement is executed, but before it is
permanently saved.
 Failed: Indicates that the transaction cannot proceed due to an error.
 Aborted: The transaction has been rolled back, and no changes have been applied.
 Committed: The transaction has been successfully completed and changes are saved
permanently to the database.
3. Concurrency Control

Concurrency control mechanisms ensure that multiple transactions can occur in a system without
leading to inconsistencies, using techniques such as:

 Locking: Transactions acquire locks on data resources to prevent other transactions from
modifying them while they are being processed.
o Example: A transaction that is updating customer information locks the customer
record to prevent other transactions from reading or writing to it until the update
is complete.
 Timestamping: Assigns a unique timestamp to each transaction to determine the order of
execution.
o Example: In a timestamp-waiting protocol, if a transaction attempts to access an
item held by a later transaction, it will wait until that transaction is completed.

4. Types of Transactions

 Single-user transactions: One user or process is executing operations on the database.

 Multi-user transactions: Multiple users or processes are interacting with the database
concurrently.

5. Transaction Management Systems

These are systems that manage transactions in addition to their processing.

 Example: A Relational Database Management System (RDBMS) like MySQL or

PostgreSQL manages transactions, ensuring that they meet ACID properties and handle
concurrency through locking mechanisms.

Schedules and Recoverability

In the context of databases, particularly in transaction processing systems, schedules and

recoverability are crucial concepts. They help ensure data integrity and consistency, especially in
environments where multiple transactions might be occurring simultaneously.

Schedules

A schedule is a sequential arrangement of transactions in which the operations (such as reads

and writes) of several transactions are interleaved. The main goal of scheduling is to optimize the
performance of the database management system while maintaining data integrity.

There are two main types of schedules:

 1. Serial Schedule: A schedule where transactions are executed one after another, without
any interleaving. This type is simple and guarantees consistency.
o Example:

 
 Schedule S1:
 T1: R(A)
 T1: W(A)
 T2: R(B)
 T2: W(B)

 Concurrent Schedule: A schedule where the operations of two or more transactions are
interleaved. This can improve system performance but can also introduce complexity and
potential inconsistencies.

 Example:

2.
o Schedule S2:
o T1: R(A)
o T2: R(B)
o T1: W(A)
o T2: W(B)
o

Recoverability

Recoverability refers to the ability of the database system to return to a consistent state after a
transaction failure, such as a crash or an error. A schedule is considered recoverable if,
whenever a transaction T1 reads a value written by another transaction T2, T1 commits only
after T2 commits. This ensures that the result of T1 can be safely used and that T2's changes are
durable.

There are a few important terms related to recoverability:

1. Strict: A strict schedule ensures that no transaction can read or write to a data item until
the previous transaction that wrote that item has committed. This is a very strong form of
consistency.
o Example:
  
 Schedule S3 (Strict):
 T1: W(A)
 T1: C
 T2: R(A)
 T2: W(B)
 T2: C

 Recoverable: A recoverable schedule allows transactions to read uncommitted data, as long

as the transaction that wrote that data commits first.

 Example:

 
 Schedule S4 (Recoverable):
 T1: W(A)
 T2: R(A)
 T1: C
 T2: C

 Cascadeless: A cascadeless schedule is one where transactions can only read data written by
committed transactions. This guarantees that a failure of one transaction does not lead to
cascading rollbacks.

 Example:

3.
o Schedule S5 (Cascadeless):
o T1: W(A)
o T1: C
o T2: R(A)
o T2: C
o

Example of Non-Recoverable Schedule

Consider the following schedule:

Schedule S6 (Non-Recoverable):
T1: W(A) (T1 writes A)
T2: R(A) (T2 reads A)
T1: C (T1 commits)
T2: W(A) (T2 writes A)
T1: R(B) (T1 tries to read B)

 In this schedule, T2 reads A before T1 commits. If T1 were to fail, T2 could end up in an

inconsistent state because it has read uncommitted data from T1. If T1 were to roll back,
T2 would be affected because of its reliance on T1's written value.

Serializability of Schedules

Serializability is a key concept in database management systems that ensures that the concurrent
execution of transactions yields the same results as if the transactions were executed serially (one
after the other, without overlapping in time). There are two main types of serializability: conflict
serializability and view serializability.

1. Conflict Serializability

Two schedules are conflict equivalent if they can be transformed into one another by swapping
non-conflicting operations. A schedule is conflict serializable if it is conflict-equivalent to a
serial schedule.

Example:

Consider the following transactions:

 T1:
o Read(A)
o Write(A)

 T2:
o Read(A)
o Write(A)

Now let's create two schedules:

Schedule S1:

1. T1: Read(A) --> (R1)

2. T2: Read(A) --> (R2)
3. T1: Write(A) --> (W1)
4. T2: Write(A) --> (W2)
Schedule S2:

1. T1: Read(A) --> (R1)

2. T1: Write(A) --> (W1)
3. T2: Read(A) --> (R2)
4. T2: Write(A) --> (W2)

 S1 is not conflict serializable because it cannot be rearranged (by swapping non-

conflicting operations) to form a serial schedule without changing the order of conflicting
operations (like W1 and W2).
 S2, on the other hand, executes T1 completely before T2, resulting in a serial schedule
and making it conflict serializable.

2. View Serializability

View serializability is a broader concept than conflict serializability. A schedule is view

serializable if it is equivalent to a serial schedule in terms of the final values of all data items and
the order of read and write operations.

Example:

Consider the following transactions:

 T1:
o Read(X)
o Write(X)

 T2:
o Read(X)
o Write(X)

Schedule S3:

1. T1: Read(X) --> (R1)

2. T2: Write(X) --> (W2)
3. T2: Read(X) --> (R2)
4. T1: Write(X) --> (W1)

In this schedule:

 T1 reads the initial value of X,

 T2 writes a new value for X,
 T2 then reads that new value,
  Finally, T1 writes another new value.

This schedule S3 is view serializable because:

 The initial value of X read by T1 could be the same as in a serial execution of T1

followed by T2.
 The final state can be matched with a serial execution of T1 followed by T2.

However, it is important to note that view serializability is generally more complex to check than
conflict serializability.

Summary

 Conflict Serializability: Focuses on the order of conflicting operations and ensures that
they can be reordered into a way that is consistent with a serial execution.
 View Serializability: Ensures that a transaction sees the same data it would in a serial
execution and that the final state matches a serial execution's outcome.

Both types are essential for ensuring consistency in concurrent transaction processing in
databases.

Transaction Support in SQL

Transaction support in SQL is essential for maintaining data integrity and ensuring that database
operations are executed reliably. A transaction is a sequence of operations performed as a single
logical unit of work. A transaction is generally characterized by four properties, often referred to
as ACID properties:

1. Atomicity: Ensures that all operations within a transaction are completed successfully or none
are.
2. Consistency: Ensures that a transaction brings the database from one valid state to another
valid state.
3. Isolation: Ensures that the operations in a transaction are isolated from other operations
happening concurrently.
4. Durability: Ensures that once a transaction is committed, it will remain so, even in the event of a
system failure.

SQL Transaction Operations

In SQL, transactions are managed using specific commands:

 BEGIN TRANSACTION: Starts a new transaction.

 COMMIT: Saves all changes made in the transaction to the database.
 ROLLBACK: Undoes all changes made in the transaction if an error occurs.

Example
Let’s look at a practical example involving a banking application. We will transfer money from
one account to another, demonstrating the use of transactions.

Assume we have a simple table called accounts:

CREATE TABLE accounts (

account_id INT PRIMARY KEY,
account_name VARCHAR(100),
balance DECIMAL(10, 2)
);

Sample Data

INSERT INTO accounts (account_id, account_name, balance) VALUES

(1, 'Alice', 500.00),
(2, 'Bob', 300.00);

Transaction Example: Transferring Money

Now, let’s create a stored procedure that transfers money from Alice to Bob. The transaction will
ensure both the debit from Alice's account and the credit to Bob's account are completed
successfully or rolled back if there is an issue.

DELIMITER //

CREATE PROCEDURE transfer_money(IN from_account INT, IN to_account INT, IN

amount DECIMAL(10, 2))
BEGIN
DECLARE insufficient_funds CONDITION FOR SQLSTATE '45000';

-- Start a transaction
START TRANSACTION;

-- Check if sufficient funds exist

IF (SELECT balance FROM accounts WHERE account_id = from_account) >=
amount THEN
-- Debit the amount from the sender's account
UPDATE accounts
SET balance = balance - amount
WHERE account_id = from_account;

-- Credit the amount to the receiver's account

UPDATE accounts
SET balance = balance + amount
WHERE account_id = to_account;

-- Commit the transaction

COMMIT;
ELSE
-- Raise error and rollback
ROLLBACK;
SIGNAL insufficient_funds SET MESSAGE_TEXT = 'Insufficient funds';
 END IF;
END //

DELIMITER ;

Calling the Procedure

To transfer, for instance, $100 from Alice to Bob, you would execute:

CALL transfer_money(1, 2, 100.00);

Explanation

1. Start Transaction: This marks the beginning of a transaction block.

2. Check Balance: The transaction checks if Alice has enough balance before proceeding.
3. Update Operations: If sufficient, it deducts the amount from Alice's account and adds it to Bob’s
account.
4. Commit: If all updates are successful, the transaction commits the changes, making them
permanent.
5. Rollback: If the balance check fails or there's an issue during the update, the transaction rolls
back to maintain data integrity