Two-Phase Commit Prepare List Communication for Coordinator Failure Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed transaction processing, when a coordinator fails, network nodes may remain in a 'ready to commit' state or keep resources locked, affecting reliability and consistency due to the inability to determine the transaction outcome without the coordinator, violating ACID properties.
Innovation Solution
A method and system for communicating a prepare list among network nodes using a two-phase commit protocol, allowing nodes to determine the transaction outcome independently during recovery, even without the coordinator, by transmitting commit determinations and using a prepare list to enable heuristic decisions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the coordinator network node is used to manage distributed transactions, then transaction coordination and commit decisions can be made centrally, but the system becomes vulnerable to coordinator failure causing nodes to remain in 'ready to commit' state indefinitely
Solution Approach 1:
The patent applies preliminary action by having each participating node determine in advance whether it can commit its process before the coordinator fails. Nodes prepare their commit determinations and store them locally, so that when coordinator failure occurs, they can immediately use this pre-prepared information to make recovery decisions without waiting for coordinator response.
Solution Approach 2:
The patent implements self-service by enabling participating nodes to autonomously determine transaction outcomes using their own stored commit determination information when the coordinator is unavailable. Each node serves itself by checking its local prepare list and commit determinations to decide whether to commit or roll back, without requiring coordinator intervention.
2Reliability
If nodes wait for coordinator confirmation to maintain atomicity, then transaction consistency is preserved, but system productivity decreases due to idle waiting during coordinator failure
Solution Approach 1:
The patent applies preliminary action by having nodes prepare their commit determinations in advance and store them in the prepare list before coordinator failure occurs. This pre-prepared information allows nodes to immediately make commit or rollback decisions during recovery without entering an idle waiting state, thus maintaining atomicity while preserving productivity.
Solution Approach 2:
The patent implements feedback by having nodes continuously monitor coordinator availability and switch to autonomous decision-making when coordinator responses are not received. The feedback mechanism triggers nodes to use their stored commit determinations from the prepare list, enabling them to maintain atomicity while avoiding prolonged waiting that would reduce productivity.
3Reliability
If nodes keep transaction resources locked during coordinator failure, then consistency is maintained, but system resource availability decreases
Solution Approach 1:
The patent applies preliminary action by having nodes determine and store their commit capability in advance in the prepare list. When coordinator failure occurs, nodes use this pre-determined information to quickly release or commit resources without prolonged locking, thus maintaining consistency while improving resource availability for other transactions.
Solution Approach 2:
The patent implements self-service by enabling nodes to autonomously manage their own resource locking and releasing decisions based on their stored commit determinations. Each node serves itself by evaluating its local prepare list information and making independent decisions to commit or rollback, thereby maintaining consistency while freeing resources promptly rather than holding them indefinitely.
Data Source
AI summary
Systems and methods are provided for prepare list communication to participants in a two-phase commit protocol transaction processing. An exemplary method includes receiving a distributed transaction for processing, wherein the processing uses a two-phase commit protocol, preparing a first participating node comprising a first process of the distributed transaction, and preparing a second participating node comprising a second process of the distributed transaction. The method further includes determining whether the first participating node can commit the first process and transmitting the determination the first participating node can commit the first process to the second participating node. The first participating node and the second participating node may determine a coordinator of the distributed transaction has failed and the second participating node may use the determination to query the first participating node for a transaction outcome, such as a commit of fail state.