Hone logo
Hone
Problems

Implementing Two-Phase Commit (2PC) in Python

Distributed systems often require ensuring atomicity across multiple independent participants. The Two-Phase Commit (2PC) protocol is a widely used algorithm to achieve this, guaranteeing that a transaction either commits successfully across all participants or aborts entirely, preventing partial updates. This challenge will guide you through implementing a simplified version of the 2PC protocol in Python to simulate distributed transaction management.

Problem Description

Your task is to implement a Python simulation of the Two-Phase Commit (2PC) protocol. You will need to create a Coordinator and multiple Participant classes. The Coordinator will initiate transactions, manage the two phases of the commit, and decide the final outcome. The Participant classes will represent individual systems that can either vote to commit or abort a transaction based on their internal state.

Key Requirements:

  1. Coordinator Class:

    • Must be able to initiate a transaction request to a list of Participant instances.
    • Must manage the "Prepare" phase: sending a "prepare" message to all participants and collecting their votes.
    • Must manage the "Commit" phase: sending either a "commit" or "abort" message to all participants based on the collected votes.
    • Must handle scenarios where a participant fails to respond or votes to abort.
    • Should maintain the transaction's state (e.g., PREPARING, COMMITTING, ABORTING, COMMITTED, ABORTED).

  2. Participant Class:

    • Must be able to receive a "prepare" message from the Coordinator.
    • Must have a mechanism to simulate its ability to either commit or abort. For simplicity, this can be a boolean flag or a simple function that returns a random outcome.
    • Must be able to vote "yes" (commit) or "no" (abort) back to the Coordinator.
    • Must be able to receive a final "commit" or "abort" message and update its internal state accordingly.
    • Should have a way to simulate potential failures (e.g., not responding to prepare, failing during commit).

  3. Simulation:

    • The implementation should focus on the logic of the 2PC protocol itself, rather than actual network communication. You can simulate messages by calling methods on objects.
    • The output should clearly indicate the state transitions of the Coordinator and Participants, as well as the final outcome of the transaction.

Expected Behavior:

  • If all participants vote "yes" in the prepare phase, the Coordinator will instruct all participants to commit.
  • If at least one participant votes "no" or fails to respond in the prepare phase, the Coordinator will instruct all participants to abort.
  • If a participant fails after voting "yes" but before receiving the commit/abort message, this scenario (though more complex in real systems) should be handled by the coordinator attempting to send the final message. For this simulation, assume participants that voted "yes" will eventually acknowledge the commit/abort.

Edge Cases to Consider:

  • A participant crashes during the "prepare" phase (does not respond).
  • A participant crashes after voting "yes" but before receiving the final commit/abort message. (For this simulation, we can simplify this by assuming they eventually receive the message if they voted yes, or the coordinator logs it as a potential issue).
  • Network partition (not explicitly simulated, but the failure to respond covers this).

Examples

Example 1: Successful Commit

# Assume 2 Participants: P1, P2
# Assume both P1 and P2 can commit

coordinator = Coordinator()
p1 = Participant("P1", can_commit=True)
p2 = Participant("P2", can_commit=True)

coordinator.add_participant(p1)
coordinator.add_participant(p2)

transaction_id = "TXN123"
coordinator.initiate_transaction(transaction_id)

# Expected Output (simplified):
# Coordinator: Initiating transaction TXN123
# Coordinator: Sending prepare to P1
# P1: Received prepare for TXN123. Voting YES.
# Coordinator: Received vote YES from P1 for TXN123
# Coordinator: Sending prepare to P2
# P2: Received prepare for TXN123. Voting YES.
# Coordinator: Received vote YES from P2 for TXN123
# Coordinator: All participants voted YES. Proceeding to commit.
# Coordinator: Sending commit to P1
# P1: Received commit for TXN123. State: COMMITTED
# Coordinator: Sending commit to P2
# P2: Received commit for TXN123. State: COMMITTED
# Coordinator: Transaction TXN123 COMMITTED.

Example 2: Abort due to one participant

# Assume 2 Participants: P1, P2
# Assume P1 can commit, but P2 cannot (e.g., due to resource constraints)

coordinator = Coordinator()
p1 = Participant("P1", can_commit=True)
p2 = Participant("P2", can_commit=False) # P2 cannot commit

coordinator.add_participant(p1)
coordinator.add_participant(p2)

transaction_id = "TXN456"
coordinator.initiate_transaction(transaction_id)

# Expected Output (simplified):
# Coordinator: Initiating transaction TXN456
# Coordinator: Sending prepare to P1
# P1: Received prepare for TXN456. Voting YES.
# Coordinator: Received vote YES from P1 for TXN456
# Coordinator: Sending prepare to P2
# P2: Received prepare for TXN456. Voting NO (cannot commit).
# Coordinator: Received vote NO from P2 for TXN456
# Coordinator: A participant voted NO. Aborting transaction.
# Coordinator: Sending abort to P1
# P1: Received abort for TXN456. State: ABORTED
# Coordinator: Sending abort to P2
# P2: Received abort for TXN456. State: ABORTED
# Coordinator: Transaction TXN456 ABORTED.

Example 3: Abort due to participant failure to respond

# Assume 2 Participants: P1, P2
# Assume P1 can commit, P2 will simulate failure to respond to 'prepare'

class FailingParticipant(Participant):
    def prepare(self, transaction_id):
        print(f"{self.name}: Received prepare for {transaction_id}. Simulating failure to respond.")
        # Do not call super().prepare() or return a vote
        return None # Or raise an exception to simulate crash

coordinator = Coordinator()
p1 = Participant("P1", can_commit=True)
p2 = FailingParticipant("P2") # P2 will not respond

coordinator.add_participant(p1)
coordinator.add_participant(p2)

transaction_id = "TXN789"
coordinator.initiate_transaction(transaction_id)

# Expected Output (simplified):
# Coordinator: Initiating transaction TXN789
# Coordinator: Sending prepare to P1
# P1: Received prepare for TXN789. Voting YES.
# Coordinator: Received vote YES from P1 for TXN789
# Coordinator: Sending prepare to P2
# P2: Received prepare for TXN789. Simulating failure to respond.
# Coordinator: Timeout or no response from P2 for TXN789. Aborting transaction.
# Coordinator: Sending abort to P1
# P1: Received abort for TXN789. State: ABORTED
# Coordinator: Sending abort to P2 (even though it didn't respond to prepare)
# P2: (May or may not receive this depending on simulation of failure)
# Coordinator: Transaction TXN789 ABORTED.

Constraints

  • The simulation should handle up to 10 participants.
  • The Coordinator should have a timeout mechanism (e.g., 1 second) for receiving votes during the prepare phase.
  • Participant's can_commit attribute should be a boolean.
  • The state of the transaction and participants should be clearly logged or printed.

Notes

  • You'll need to implement the logic for the two phases: "Prepare" and "Commit/Abort".
  • Consider how to represent the messages exchanged between the coordinator and participants. Method calls are a good abstraction for this simulation.
  • Think about how to manage concurrency if you were to extend this to actual parallel execution, but for this challenge, a sequential simulation is sufficient.
  • The Coordinator's decision to commit or abort hinges on all participants voting "yes". If even one votes "no" or fails to respond, the transaction must be aborted.
Loading editor...
python