Two-Phase Commit Implementation in Python

Two-phase commit (2PC) is a distributed algorithm ensuring atomicity across multiple participants in a transaction. This challenge asks you to implement a simplified version of 2PC in Python, focusing on the core logic of the prepare and commit phases. This is crucial for maintaining data consistency in distributed systems where a single transaction might involve updates to multiple databases or services.

Problem Description

You are tasked with implementing a basic two-phase commit protocol between a coordinator and multiple participants. The coordinator initiates the transaction and orchestrates the commit process. Participants vote on whether they can commit their portion of the transaction. The coordinator then decides whether to commit or abort the transaction based on the votes received.

What needs to be achieved:

• Implement a Coordinator class that manages the transaction and interacts with the Participants.
• Implement a Participant class that represents a resource (e.g., a database) and participates in the 2PC protocol.
• The coordinator should send a "prepare" message to all participants.
• Participants should respond with either "yes" (ready to commit) or "no" (cannot commit).
• The coordinator should collect the votes and decide whether to commit or abort.
• If the coordinator decides to commit, it sends a "commit" message to all participants.
• If the coordinator decides to abort, it sends an "abort" message to all participants.
• Participants should acknowledge the final decision (commit or abort).

Key Requirements:

• The implementation should clearly demonstrate the two phases: prepare and commit/abort.
• Participants should simulate a resource that can either commit or abort.
• The coordinator should handle the case where one or more participants vote "no."
• The coordinator should handle timeouts (simulated) to prevent indefinite blocking.

Expected Behavior:

• When the coordinator initiates a commit, all participants should either commit or abort their portion of the transaction.
• If any participant cannot commit, the entire transaction should be aborted.
• The coordinator should log all actions and decisions.
• Participants should acknowledge the final decision.

Edge Cases to Consider:

• What happens if a participant fails to respond to a message? (Simulate this with a timeout)
• What happens if the coordinator fails? (This is beyond the scope of this simplified implementation, but consider how it would impact the system)
• How does the system handle concurrent transactions? (Not required for this challenge, but a good consideration)

Examples

Example 1:

Input: Coordinator initiates commit with 2 participants, both vote "yes".
Output: Coordinator sends "commit" to both participants. Both participants acknowledge "committed".
Explanation: All participants are ready to commit, so the coordinator commits the transaction.

Example 2:

Input: Coordinator initiates commit with 2 participants, one votes "yes", one votes "no".
Output: Coordinator sends "abort" to both participants. Both participants acknowledge "aborted".
Explanation: One participant cannot commit, so the coordinator aborts the transaction.

Example 3: (Timeout Scenario)

Input: Coordinator initiates commit with 2 participants. Participant 1 votes "yes" but Participant 2 times out.
Output: Coordinator sends "abort" to both participants. Both participants acknowledge "aborted".
Explanation: Participant 2 did not respond within the timeout period, so the coordinator aborts the transaction.

Constraints

• The number of participants should be between 1 and 5 (inclusive).
• Participants should simulate their readiness to commit with a 50% probability (either "yes" or "no").
• Timeout for participant responses should be 2 seconds.
• The implementation should be reasonably efficient (avoid unnecessary loops or complex data structures).
• Use Python's built-in threading or asyncio for simulating asynchronous communication (optional, but encouraged).

Notes

• This is a simplified implementation of 2PC. Real-world implementations are more complex and involve considerations like fault tolerance, logging, and security.
• Focus on demonstrating the core concepts of the prepare and commit/abort phases.
• You can use simple print statements for logging and communication between the coordinator and participants.
• Consider using a thread pool or asynchronous programming to simulate concurrent participant responses. This will make the simulation more realistic.
• Error handling (e.g., handling exceptions during communication) is not required for this challenge, but good practice for real-world implementations.