UNIT IV

(SAQs)1. What is a transaction? Sketch and explain the transaction state diagram.
A transaction is a unit of program execution that accesses and possibly updates data. A
transaction ensures that database integrity is maintained despite system failures or concurrent
executions.
State diagram:

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

 Partially committed: After the last statement is executed.
 Failed: If an error occurs, the transaction cannot proceed.
 Aborted: Transaction rolled back to its initial state; can be restarted or terminated.
 Committed: Changes are saved permanently.

2. Summarize ACID properties.

 Atomicity: Ensures all operations are completed or none at all.

 Consistency: Database remains consistent before and after the transaction.
 Isolation: Concurrent transactions do not interfere with each other.
 Durability: Committed transactions remain permanent despite failures.

3. Explain how transaction atomicity and durability are implemented.

Atomicity is implemented via log-based recovery or shadow paging. In case of failure,
incomplete transactions are undone using logs or the old database state.
Durability is ensured by writing changes to stable storage before committing, guaranteeing
persistence.

4. Explain how transaction isolation is implemented.

Isolation is managed through concurrency control protocols such as:

 Lock-based protocols: Shared and exclusive locks to prevent conflicts.

 Timestamp-based protocols: Ordering transactions to maintain serializability.
 Validation-based protocols: Transactions validate data consistency before
committing.

5. Define schedule. List the types of schedules.

A schedule is a sequence of transaction operations executed in a specific order.
Types:

 Serial schedule: Transactions executed sequentially.

  Concurrent schedule: Transactions executed concurrently.
 Conflict-serializable: Equivalent to a serial schedule based on operation swaps.
 View-serializable: Equivalent to a serial schedule based on the view of transactions.

6. What is the use of serializability in transactions?

Serializability ensures that the outcome of concurrent transactions is the same as if they were
executed sequentially, maintaining database consistency.

7. What is a cascading rollback and a cascadeless schedule?

 Cascading rollback: Failure of one transaction causes multiple rollbacks due to

dependencies.
 Cascadeless schedule: Ensures a transaction reads only committed data, preventing
cascading rollbacks.

8. Discuss conflicts arising from insert and delete operations.

Insert and delete operations can cause phantom problems where the set of tuples accessed
changes during execution. To prevent issues:

 Use index locking protocols to lock specific index entries.

 Lock metadata associated with relation structure.

9. Short notes:

 Phantom phenomenon: Occurs when range queries miss newly inserted tuples due
to lack of proper locking.
 Cursor stability: Locks a tuple only during access; read locks are released
immediately after reading.
 Weak isolation levels:
o Read uncommitted: May read uncommitted changes.
o Read committed: Reads committed data but doesn’t ensure repeatable reads.
o Repeatable read: Ensures same data read in multiple operations but doesn’t
prevent phantoms.
 Starvation problem: A transaction continuously waits due to others being
prioritized, often mitigated by fair scheduling.

10. What is a deadlock? How to handle it?

A deadlock occurs when a set of transactions wait indefinitely for each other to release
resources.
Handling methods:
  Prevention: Using wait-die or wound-wait schemes.
 Detection: Using wait-for graphs to find cycles.
 Recovery: Aborting and rolling back transactions to break deadlocks.

(LAQS)Detailed Answers to Transaction and Concurrency Control Questions

1. Conflict Serializability

Conflict serializability ensures that the schedule of transactions can be rearranged into a serial
schedule using a sequence of swaps of non-conflicting operations. Conflicts occur when two
transactions perform operations on the same data item, and at least one of them is a write
operation.

Steps to Test Conflict Serializability:

1. Identify Transactions and Operations: List all read and write operations in the schedule.

2. Build the Precedence Graph:

o Create a node for each transaction.

o Draw directed edges between transactions if they conflict (e.g., one transaction
writes a data item that another reads).

3. Check for Cycles: If the precedence graph has no cycles, the schedule is conflict-serializable.

Example: Consider transactions T1 and T2:

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

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

Schedule: T1: Read(A), T2: Read(A), T1: Write(A), T2: Write(A)

Graph Construction:

 T1 → T2 (T1 writes A before T2 reads A).

 T2 → T1 (T2 writes A before T1 reads A).

The graph has a cycle, so the schedule is not conflict-serializable.

Conflict serializability guarantees consistency and is essential for ensuring that concurrent
transactions produce the same result as sequential execution.

2. View Serializability

View serializability ensures schedules produce the same final result as a serial schedule. It is broader
than conflict serializability and includes some schedules that are not conflict-serializable.

Conditions for View Equivalence:

1. Same Initial Reads: Transactions reading initial values must match across schedules.
 2. Same Intermediate Reads: For every data item read, the value must come from the same
transaction.

3. Same Final Writes: The final write of every data item in the schedule must be the same.

Example:

 T1: Write(A=10), T2: Read(A), Write(A=20)

 T3: Read(A), Write(A=30)

View Serializability checks if another serial schedule (e.g., T1 → T2 → T3) produces the same reads
and writes as the original schedule. If it does, the schedule is view-serializable.

View serializability is harder to test as it requires analyzing all potential serial schedules, but it
captures more permissible schedules compared to conflict serializability.

3. Locks and Their Types

Locks control access to data to ensure consistency and isolation. Two primary lock types are:

1. Shared (S) Lock: Allows multiple transactions to read a data item simultaneously but
prevents writing.

2. Exclusive (X) Lock: Allows one transaction to read and write a data item, blocking others.

Locking Protocols:

 Two-Phase Locking (2PL): Divides the transaction into:

o Growing Phase: Acquiring locks.

o Shrinking Phase: Releasing locks.

 Strict 2PL: Holds all locks until the transaction commits or aborts.

 Rigorous 2PL: Keeps all locks until commit, including shared locks.

Example:

 T1: Lock-X(A), Write(A), Unlock(A).

 T2: Lock-S(A), Read(A), Unlock(A).

This ensures that T1’s write is not interfered with by T2’s read.

4. Lock-Based Protocols

Lock-based protocols are mechanisms for maintaining transaction serializability and isolation.

Key Variants:

1. Basic Two-Phase Locking: Ensures serializability by restricting the order of acquiring and
releasing locks.

2. Strict Two-Phase Locking: Avoids cascading rollbacks by holding exclusive locks until commit.
 3. Rigorous Two-Phase Locking: Retains both shared and exclusive locks until commit,
providing stronger isolation.

Advantages:

 Prevents data corruption due to concurrent writes.

 Guarantees serializability.

Disadvantages:

 May lead to deadlocks and lower concurrency.

 Starvation if transactions are repeatedly denied access.

5. Timestamp Ordering Protocols

This protocol assigns a unique timestamp to each transaction, dictating the order of operations to
ensure serializability.

Steps:

1. Assign timestamps based on transaction arrival.

2. Order operations by timestamps.

3. Rollback conflicting transactions to maintain order.

Example:

 T1: Timestamp = 1, T2: Timestamp = 2.

 If T2 tries to write data already read by T1, T2 is rolled back.

Timestamp ordering prevents deadlocks but can cause cascading rollbacks if dependencies exist.

6. Validation-Based Protocols

This optimistic approach assumes minimal conflicts and validates transactions before committing.

Phases:

1. Read Phase: Transaction reads data and performs operations on local copies.

2. Validation Phase: Checks if the transaction conflicts with others.

3. Write Phase: Commits changes if validation succeeds.

Example:

 T1 reads A and B.

 T2 writes to A during T1’s read phase.

 Validation detects the conflict and aborts T1.

Validation protocols are ideal for low-conflict scenarios and allow higher concurrency.
7. Multiple Granularity Locks

Granularity refers to the size of the data item being locked (e.g., database, table, row).

Lock Hierarchy:

1. Database level

2. Table level

3. Row level

Intention Locks: Indicate a transaction’s intention to acquire specific locks at a finer granularity.

Example:

 T1 locks a table in IS mode, indicating it will acquire shared locks on rows.

 T2 locks a row in X mode, preventing T1 from escalating its lock.

This strategy balances concurrency and overhead by allowing finer-grained locking when necessary.

8. Deadlock Prevention, Detection, and Recovery

Deadlock: A state where transactions wait indefinitely for resources held by each other.

Prevention Strategies:

1. Wait-Die Scheme: Older transactions wait; younger transactions are rolled back.

2. Wound-Wait Scheme: Older transactions force younger ones to roll back.

3. Timeouts: Transactions that wait too long are aborted.

Detection:

 Use a wait-for graph to detect cycles.

 Periodically check for cycles and break them.

Recovery:

 Rollback one or more transactions to resolve deadlock.

 Choose victims based on cost (e.g., least progress).

By combining these strategies, systems can handle deadlocks effectively while maintaining high
concurrency.
 UNIT V
Short Answer Questions:

1. Summarize different types of failures:

 Transaction Failures:

o Logical Errors: Internal errors within a transaction, such as invalid operations or

constraints.

o System Errors: System forcibly terminates a transaction, e.g., due to deadlocks.

 System Crashes: Hardware or software failures causing system downtime (e.g., power
failure).

 Disk Failures: Physical issues like disk crashes that may destroy data.

2. Different types of database storages:

 Volatile Storage: Temporary, lost during crashes (e.g., main memory, cache).

 Nonvolatile Storage: Persistent, survives crashes (e.g., disks, SSDs).

 Stable Storage: Hypothetical, approximated using redundant copies on multiple media.

3. Short notes on checkpoints:

 Purpose:

o Simplify recovery by recording a consistent database state periodically.

 Steps:

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

2. Write modified buffer blocks to disk.

3. Add <checkpoint> record to the log.

 Advantages:

o Limits the amount of log scanning during recovery.

o Reduces the need for redundant redo operations.

4. What is NoSQL? Applications of NoSQL:

  Definition: NoSQL databases are non-relational databases designed for large-scale, high-
velocity data storage with flexible schemas.

 Applications:

o Real-time web analytics and big data processing (e.g., Hadoop integration).

o Internet of Things (IoT) and sensor data storage.

o Content management systems.

o Social media platforms and recommendation engines.

Long Answer Questions:

1. Discuss log-based recovery techniques:

Log-based recovery ensures atomicity and durability by maintaining a log of all transaction
operations.

 Types of Logging:

o Deferred Database Modification: Writes are recorded in logs but deferred until
commit. Ensures no partial changes occur.

o Immediate Database Modification: Allows changes during execution. Requires undo

and redo operations.

 Recovery Phases:

o Undo: Reverts uncommitted changes by applying pre-logged old values.

o Redo: Reapplies changes from committed transactions using log entries.

Logs are critical in maintaining database consistency, even during system crashes or failures.

2. Explain buffer management:

Buffer management optimizes disk I/O by maintaining frequently accessed data in memory.

 Mechanisms:

o Log Buffering: Writes logs in batches to reduce I/O overhead.

o Database Buffering: Keeps active database blocks in memory, writing them back
when needed.

 Key Practices:

o Follow Write-Ahead Logging (WAL): Logs are written before data is flushed to disk.

o Avoid dual paging: Coordinate OS and DB buffer management to prevent redundant

I/O operations.
3. Explain remote backup systems:
Remote backups ensure high availability by replicating database states to a secondary site.

 Features:

o Failure Detection: Detect primary site failure using redundant communication links.

o Control Transfer: Backup recovers using received logs and becomes the new primary.

o Hot Spare: Backup processes logs continuously for faster recovery.

 Commit Strategies:

o One-Safe: Commit after logging at primary site.

o Two-Safe: Commit after logging at both primary and backup sites.

o Two-Very-Safe: Highest durability but lower availability.

4. Types of NoSQL databases with examples:

 Document Stores (e.g., MongoDB): JSON-like documents, suitable for semi-structured data.

 Key-Value Stores (e.g., Redis): Simple key-value pairs for caching and session management.

 Column-Family Stores (e.g., Cassandra): Wide-column structures for analytics on distributed

data.

 Graph Databases (e.g., Neo4j): Node-edge relationships for social networks and
recommendation engines.

5. Compare RDBMS and NoSQL:

Aspect RDBMS NoSQL

Schema Fixed schema, structured. Flexible, schema-less.

Scaling Vertical scaling. Horizontal scaling.

Query Language SQL. API or query-specific.

Transaction Strong ACID compliance. BASE (eventual consistency).

Use Cases OLTP systems, banking. Big data, real-time apps.

6. Basic CRUD operations in NoSQL with examples:

 Create: Insert data using simple commands.

o Example (MongoDB): db.collection.insert({"name": "Alice"}).

 Read: Retrieve specific or all records.

o Example: db.collection.find({"name": "Alice"}).

  Update: Modify existing records.

o Example: db.collection.update({"name": "Alice"}, {$set: {"age": 30}}).

 Delete: Remove records based on criteria.

o Example: db.collection.remove({"name": "Alice"}).

NoSQL simplifies CRUD operations, offering flexibility and scalability for modern applications.