distributed part 2

atomic commit protocol

Either ALL the participating nodes commit the transaction or NONE of them do.

It guarantees Atomicity in distributed transactions.

It is used when a single transaction runs across multiple databases/servers.

why needed

Because in distributed systems…

• One server may succeed

• Another may fail

• Network may break

• Messages may get lost

ACP ensures no partial updates, meaning the system does not end up in an inconsistent state.

how it work

All atomic commit protocols follow 3 key ideas:

1. Coordinator collects responses from all participants

2. If ALL are ready → commit

   1. If ANY ONE fails → abort everywhere

Types of Atomic Commit Protocols

two tpe

1)2 phase atomic commit protocol

2) 3 phase

Two-Phase Commit Protocol (2PC)

Phase 1: Prepare Phase

• Coordinator asks: "Are you ready?"

• Participants reply: “YES” (vote commit) or “NO” (vote abort)

Phase 2: Commit/Abort Phase

• If all voted YES → coordinator sends COMMIT

• If anyone voted NO → coordinator sends ABORT

3 phase

3PC is an improved version of Two-Phase Commit (2PC) designed to solve one major problem:

🛑 2PC can block forever if the coordinator fails.

3PC solves this by adding an extra phase that makes the protocol non-blocking

1⃣ Phase 1 — CanCommit? (Voting phase) Coordinator → Participants

“Can you commit?”

Participants reply:

• YES → voteCommit

• NO → voteAbort

• Phase 2 — PreCommit (Tentative commit)

  This is the new phase introduced in 3PC to avoid blocking.

  Coordinator → Participants

  “Prepare for commit. Do not commit yet. Just save your state.”

  Participants actions:

  • Write all records to log (stable storage)

  • Lock the resources

  • Go to prepared state

  • Send ACK to coordinator

3⃣ Phase 3 — DoCommit (Final commit)

After the coordinator gets ACK from all participants:

concurrency

1. Coordinator → Participants: “Final COMMIT.”

2. Participants: Commit the transaction and release all locks.

3. Participants: Write the commit log and optionally send ACK.

If coordinator wants to abort (rare case):

• It sends ABORT instead of commit.

concurrency control in distributed transaction

It means making sure that many transactions running at the same time on different computers do not interfere with each other and do not corrupt shared data, even when the data is stored on different sites.

example - railway ticket

Techniques for Concurrency Control in Distributed Transactions

A. Distributed Two-Phase Locking (Distributed 2PL)

B. Distributed Timestamp Ordering (TO)

distributed deadlocks

A distributed deadlock occurs in a distributed system when a set of transactions running on different sites hold resources and wait for each other in a circular chain, such that none of them can proceed.

Example: Two-Site Deadlock

• Site A:

  • T1 has Lock(X)

  • T1 requests Lock(Y) → located at Site B

• Site B:

  • T2 has Lock(Y)

  • T2 requests Lock(X) → located at Site A

Conditions for Distributed Deadlock

Same as single-system but occurs across sites:

1. Mutual exclusion

2. Hold and wait

3. No preemption

4. Circular wait (critical in distributed contexts)

transaction recovery

Transaction recovery means fixing the database after something goes wrong (crash, power failure, server failure) so that:

• All completed transactions remain stored, and

• All incomplete transactions are undone safely.

Recovery technique

1. Immediate Update (UNDO + REDO)

Updates are written to the database before transaction commits.

Therefore:

• If transaction commits → REDO needed

• If transaction aborts/fails → UNDO needed

2. Deferred Update (REDO only)

Updates are written to database only after commit.

Therefore:

• No need to UNDO

• Only REDO committed transactions after crash