Why are log records important in recovery? Show state diagram of 2PC and 3PC protocols. What is blocking and non-blocking protocol?

by

Importance of Log Records in Recovery

In database systems, log records are crucial for recovering the database to a consistent state after a failure, like a system crash. Log records store the details of what changes were made by each transaction. These records are used to:

  1. Redo transactions: If a transaction was committed but the changes were not saved due to a crash, the log can be used to redo that transaction.
  2. Undo transactions: If a transaction was not committed (i.e., it failed or was rolled back), the log can be used to undo any changes that the transaction made.
  3. Restore consistency: After a crash, the log helps bring the database back to a correct state by ensuring that only fully completed transactions are applied.

2-Phase Commit (2PC) Protocol

The 2-Phase Commit (2PC) protocol is used to ensure that a transaction involving multiple databases (in a distributed system) either commits (completes) or rolls back (aborts) entirely.

Phases of 2PC:

  1. Phase 1 (Voting Phase): The coordinator (the main controller) sends a prepare message to all participants (other databases). The participants respond with either:
    • Yes (they are ready to commit).
    • No (they cannot commit).
  2. Phase 2 (Commit or Rollback Phase):
    • If all participants responded Yes, the coordinator sends a commit message, and everyone commits the transaction.
    • If any participant responded No, the coordinator sends a rollback message, and everyone rolls back the transaction.

State Diagram of 2PC:

Coordinator:
Start --> Send Prepare --> Get Votes (Yes/No) --> Commit or Rollback --> End

Participants:
Start --> Wait for Prepare --> Respond (Yes/No) --> Wait for Commit/Rollback --> End
  • Problem: If the coordinator crashes before sending the final message, the system is in a blocked state and cannot proceed.

3-Phase Commit (3PC) Protocol

The 3-Phase Commit (3PC) protocol improves upon 2PC by adding an extra phase to avoid blocking. In this protocol, if a crash happens, the system can still recover without being stuck.

Phases of 3PC:

  1. Phase 1 (Can Commit Phase): The coordinator asks all participants if they are ready to commit.
    • Participants reply Yes (ready to commit) or No (not ready).
  2. Phase 2 (Pre-Commit Phase): If all participants reply Yes, the coordinator tells them to prepare to commit but not finalize yet (pre-commit).
  3. Phase 3 (Commit Phase): The coordinator tells everyone to commit the transaction. Participants finalize the commit once they receive the commit message.

State Diagram of 3PC:

Coordinator:
Start --> Send Can Commit --> Get Votes (Yes/No) --> Send Pre-Commit --> Get Final Response (Commit/Rollback) --> End

Participants:
Start --> Wait for Can Commit --> Respond (Yes/No) --> Wait for Pre-Commit --> Finalize Commit/Rollback --> End
  • Benefit: If the coordinator crashes at any phase, the system can still decide whether to commit or abort the transaction. This avoids the blocking problem of 2PC.

Blocking and Non-Blocking Protocols

  • Blocking Protocol:
    • A blocking protocol is one where the system can get stuck (or “blocked”) if something goes wrong. For example, if the coordinator crashes in a 2PC protocol, the system will not be able to decide whether to commit or abort, and the process will remain blocked.
    • Example: 2PC is a blocking protocol because if the coordinator crashes, the transaction is stuck and can’t be completed until the coordinator comes back online.
  • Non-Blocking Protocol:
    • A non-blocking protocol ensures that even if a failure happens (like a crash), the system can still make a decision and continue. It ensures that the transaction will eventually either commit or abort without getting stuck.
    • Example: 3PC is a non-blocking protocol because even if the coordinator or any participant crashes, the system can still resolve the situation and continue.

Hence, Log records are essential for recovering the database after a failure by helping to either redo or undo transactions. 2PC ensures that a transaction across multiple systems is either fully committed or fully aborted but can block if a crash happens. 3PC improves on 2PC by adding an extra phase to avoid blocking and ensure the system can continue even if there’s a failure. Blocking protocols can leave the system stuck if something goes wrong, while non-blocking protocols guarantee that the transaction will either commit or abort, even in the case of a failure.

Leave a Comment