Database Summary, Transactions

Transaction Management and Concurrency Control

Part 1: Fundamentals of Transactions
Definition:

A transaction is a logical unit of work executed on a database that either completes entirely
(commit) or has no effect (rollback). It ensures that the database moves from one consistent state
to another.

Key Properties (ACID):

1. Atomicity:
All operations of a transaction must either be completed or none at all.
Example 1: Transferring $100 from Account A to Account B. If the debit succeeds but the
credit fails, the entire transaction rolls back.
Example 2: Booking a flight and hotel together; if one fails, the transaction is aborted.
Example 3: A banking system ensuring both withdrawal and deposit are executed or
reversed.
2. Consistency:
Ensures the database remains valid before and after the transaction.
Example 1: A transaction updating a product’s price ensures no violations of business
rules.
Example 2: Constraints like foreign keys and unique keys are maintained.
Example 3: Calculating taxes and ensuring derived values match database constraints.
3. Isolation:
Concurrent transactions do not interfere with each other.
Example 1: Two users updating the same inventory do not see intermediate results.
Example 2: Reading data while another transaction modifies it uses locks to prevent
anomalies.
Example 3: Concurrent bank withdrawals ensure balance consistency.
4. Durability:
Committed transactions are permanent, even in the event of a failure.
 Example 1: A completed order in an e-commerce system remains recorded despite a
server crash.
Example 2: Bank transfers are not reversed after confirmation.
Example 3: Data backups ensure transactions persist.

SQL Commands:

1. BEGIN TRANSACTION: Marks the start of a transaction.

2. COMMIT: Finalizes changes.
3. ROLLBACK: Reverts changes made during a transaction.

Part 2: Transaction Problems

Lost Updates:

Occurs when concurrent transactions overwrite each other’s updates.

Example 1: Two users updating the stock quantity of a product simultaneously; one update
overwrites the other.
Example 2: Two employees modifying the same record; one’s update is lost.
Example 3: Concurrent edits to a shared document without synchronization.

Uncommitted Data:

Occurs when one transaction reads data from another uncommitted transaction.

Example 1: A transaction rolls back after another has read its intermediate changes.
Example 2: Transaction A updates a balance; Transaction B reads the uncommitted balance.
Example 3: A failed banking transaction causing incorrect intermediate balance views.

Inconsistent Retrievals:

Occurs when a transaction reads partially updated data.

Example 1: Reading sales data while another transaction updates it.

Example 2: Summing product quantities before and after an update.
Example 3: Calculating a report with incomplete data due to concurrent updates.
Part 3: Concurrency Control
Purpose:

Ensure serializability, meaning concurrent transactions yield the same result as if executed
sequentially.

Locking Mechanisms:

1. Binary Locks:
Data items are either locked (1) or unlocked (0).
Example 1: Locking a file for editing and releasing it after saving.
Example 2: Preventing access to a record during updates.
Example 3: Blocking read/write access during critical operations.
2. Exclusive Locks:
Reserved for transactions performing writes.
Example 1: Editing a document to prevent simultaneous changes.
Example 2: Updating inventory stock levels.
Example 3: Modifying customer details in a database.
3. Shared Locks:
Allows multiple transactions to read data but prevents writes.
Example 1: Viewing account balance while it is updated.
Example 2: Reading product information without changes.
Example 3: Generating reports while ensuring data integrity.

Granularity of Locks:

1. Database-level:
Entire database is locked.
Example 1: Maintenance mode locking all operations.
Example 2: Bulk updates preventing concurrent access.
Example 3: Backup operations.
2. Table-level:
Specific tables are locked.
Example 1: Updating product prices locks the products table.
Example 2: Inserting records into an orders table.
Example 3: Restricting access to a customer table during cleanup.
3. Page-level:
Disk pages are locked.
 Example 1: Updating records spanning multiple pages.
Example 2: Reading a single page without locking others.
Example 3: Modifying data blocks in memory.
4. Row-level:
Specific rows are locked.
Example 1: Updating a single customer’s details.
Example 2: Modifying one order in an orders table.
Example 3: Adding a product to a specific category.
5. Field-level:
Specific fields in a row are locked.
Example 1: Updating a phone number without locking the entire record.
Example 2: Changing a single attribute of a product.
Example 3: Adjusting only the discount percentage.

In-Depth Exploration: The Scheduler and Advanced

Techniques in Transaction Management
Part 1: The Scheduler
Definition and Purpose

The scheduler is a specialized DBMS program responsible for managing the execution order
of concurrent transactions.
Goals:
Ensure serializability, meaning the results of interleaved transactions match those of
serial execution.
Maintain isolation, ensuring that no two transactions interfere with each other’s
operations.

Interleaved Execution

Interleaving transactions helps improve system efficiency but introduces challenges like
conflicts.
Serializable Schedule:
Produces the same outcome as executing transactions one after another.
Transactions that cannot be serialized are executed using First-Come-First-Serve
(FCFS), which is inefficient due to idle CPU time during read/write operations.
Facilitating Data Isolation

The scheduler ensures two transactions do not update the same data element simultaneously.
Conflict Example:
Transaction T1: Write(X).
Transaction T2: Write(X).
If both transactions execute concurrently, inconsistencies arise.

Worked Example: Scheduling Transactions

Scenario:

Transactions T1 and T2 execute concurrently:

Operation T1 T2
Step 1 Read(X)
Step 2 Write(X)
Step 3 Write(X)
Step 4 Commit

Logic Explanation:

In Step 1, T1 reads X and acquires a shared lock to prevent other transactions from writing.
In Step 2, T2 attempts to write X but must wait because T1 holds a shared lock.
In Step 3, T1 writes X and upgrades its lock to exclusive. Only after T1 commits can T2
proceed to Step 4.
This ensures serializability and avoids conflicts.

Precedence Graph for Serializability

Nodes: T1, T2.

Edges: Directed edge from T1 to T2 if T1 writes X before T2 reads or writes it.

Logic Explanation:

Construct nodes representing transactions (T1, T2).

Draw edges for dependencies: If T1 writes before T2 reads/writes, add T1 → T2.
 Check for cycles. Absence of cycles means the schedule is serializable.

Part 2: Two-Phase Locking Protocol (2PL)

Phases:

1. Growing Phase:
The transaction acquires all required locks but does not release any.
2. Shrinking Phase:
The transaction releases locks and cannot acquire new ones.

Worked Examples

Example 1: Updating and Deleting Records

T1: Update record A, Delete record B.

Operation Lock Action

Step 1: Lock A Exclusive Updates A
Step 2: Lock B Exclusive Deletes B
Step 3: Release A -
Step 4: Release B -

Logic Explanation:

During Step 1, an exclusive lock is acquired on A to prevent any other transaction from
modifying it.
Step 2 involves locking B exclusively before deletion.
After the operations are completed, locks are released in the shrinking phase to allow other
transactions access.

Example 2: Payroll Processing

T1: Calculate salaries.

Operation Lock Action

Step 1: Lock Employee Row-level Calculate salary
 Operation Lock Action
Step 2: Release Lock - Move to next employee

Logic Explanation:

Each employee record is locked during salary calculation to prevent conflicts.

After processing one record, the lock is released to reduce contention.

Example 3: Batch Updates

T1: Update product prices.

Operation Lock Action

Step 1: Lock Product Row-level Update price
Step 2: Release Lock - Move to next product

Logic Explanation:

Each product row is locked individually to allow other transactions to operate on unaffected
rows.
Locks are released sequentially to maintain efficiency and isolation.

Part 3: Deadlock Management

Detection

The system periodically checks for cycles in the resource allocation graph.
Worked Example:

Transaction Resource Held Resource Requested

T1 X Y
T2 Y X

Logic Explanation:

Represent transactions as nodes and resources as edges.

 A cycle (T1 → Y → T2 → X → T1) indicates a deadlock.
Resolve by aborting one transaction (e.g., T2) and releasing its resources.

Prevention

Transactions are aborted preemptively if they risk causing deadlocks.

Worked Example:
Lock resources in a specific order (e.g., X before Y).

Logic Explanation:

Define a strict order for acquiring locks to eliminate circular waits.

Abort transactions that violate this order.

Avoidance

Transactions acquire all locks before execution.

Worked Example: Batch processes pre-lock all required resources.

Logic Explanation:

Ensure that all necessary locks are acquired upfront.

If a lock cannot be granted, the transaction is delayed until it can proceed without conflict.