Skip to main content

ACP roles; CC methods in transactions

Short answer

Atomic commit protocols ensure all participants reach the same commit/abort decision via a coordinator collecting votes; participants save durable state, can veto, and support recovery. Concurrency control methods: locking (strict 2PL per server, distributed deadlock possible), timestamp ordering (globally unique timestamps, abort on conflict), and optimistic (validation during commit, global order).

What are the roles of atomic commitment protocol (ACP) in distributed transactions? Explain the different methods of concurrency control in distributed transactions.

Roles of atomic commitment protocol

An atomic commitment protocol (ACP) makes sure that a distributed transaction, which has operations at several servers, is either committed at all of them or aborted at all of them. Its roles are:

  • Ensure atomicity: all participants reach the same decision (commit if all vote Yes, otherwise abort).
  • A coordinator collects votes and announces the decision; participants vote and carry it out.
  • Ensure durability: participants save tentative changes to permanent storage before voting Yes, so the decision can be completed after a crash.
  • Allow any participant to veto (abort) the transaction.
  • Provide recovery from crashes and lost messages using logs and timeouts.

Concurrency control in distributed transactions

In a distributed transaction the objects are on different servers, and each server applies its own concurrency control. All servers must agree on the serialization order, otherwise the transactions could be serial at each server but not globally.

  • Locking: each server locks its own objects. Strict 2PL is used, with locks held until the commit protocol completes. A transaction's locks are held at several servers, so distributed deadlock is possible, and the servers must detect or avoid it.
  • Timestamp ordering: transactions are given globally unique timestamps (a pair of the local clock value and the server id; the servers' clocks are kept roughly synchronized). Each server enforces timestamp rules; if the servers order conflicting transactions the same way, the result is globally serializable. A conflict causes an abort at any server, which aborts the whole transaction.
  • Optimistic: each server validates the part of the transaction it holds, during the first phase of commit. Validation must produce a consistent order across servers, so a global or ordered validation is needed.

The basic methods used at each server are:

  1. Locking (pessimistic): a transaction locks data before access and holds it (strict 2PL) until commit. Conflicts cause waiting; deadlock is possible.
  2. Timestamp ordering: each transaction gets a timestamp; conflicting operations must be executed in timestamp order; late operations abort the transaction. No deadlock.
  3. Optimistic concurrency control: work on private copies, validate at commit time, and abort if there was a conflict.

✓ Answer checked by Claude Opus 5.5 (high effort)

Related questions

All Distributed System chapter 8 questions →