Distributed Transaction Orchestration for Restart Recovery Without Rollback
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing transaction control systems face challenges in suppressing rollback processing of undecided transactions due to system failures, particularly when managing multiple transactions in parallel, leading to increased load and uncertainty in transaction recovery.
Innovation Solution
A transaction control system with an orchestrator and proxy devices that record a flag indicating the progress of processing flows for undecided transactions, allowing for informed decision-making upon system restart to suppress rollback processing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If the system manages only the states of start and update completion of transactions, then the state management load is reduced, but all transactions must be rolled back if a system failure occurs
Solution Approach 1:
The patent segments the transaction state management into two levels: coarse-grained state management (managed by the transaction control system) and fine-grained state management (managed by proxy devices). The proxy devices independently track the progress of each transaction (Try, Confirm, or Cancel phase), while the transaction control system manages the overall transaction state. This segmentation allows the system to maintain detailed transaction progress information without overloading the central control system, resolving the contradiction between management complexity and recovery reliability.
2Measurement precision
If the system manages detailed states of multiple transactions in parallel, then transaction recovery accuracy is improved, but the management load increases in proportion to the number of transactions
Solution Approach 1:
The patent divides the state management responsibility between the transaction control system and proxy devices. Proxy devices manage detailed transaction state information locally, while the transaction control system maintains only high-level transaction state. This distribution eliminates the need for the central system to track every detail of every transaction, reducing management load while preserving measurement precision through local proxy tracking.
Solution Approach 2:
The proxy device acts as an intermediary between the transaction control system and external services. It captures and stores transaction progress information (Try, Confirm, or Cancel phase) locally, serving as a buffer that preserves detailed state information without requiring the central control system to directly manage all transaction details. This intermediary approach maintains measurement precision while reducing overall system complexity.
3Reliability
If the system selects Rollback for undecided transactions after failure, then data consistency is ensured, but processing time increases and productivity decreases
Solution Approach 1:
The patent implements preliminary action by having proxy devices capture and store transaction progress information (Try, Confirm, or Cancel phase) at the time of failure. This预先 captured state information is retained even after system restart, allowing the system to resume transaction processing from the exact point of failure without requiring complete rollback and re-execution. This preserves data consistency while dramatically reducing processing time and improving productivity.
Solution Approach 2:
The system prepares for future failures by maintaining transaction state information in proxy devices that survive system restarts. This beforehand cushioning of state information ensures that when failures occur, the system can quickly resume from the captured state rather than starting over, thus ensuring data consistency while minimizing productivity loss.
Data Source
AI summary
Provided is a transaction control system, method, and program that suppress Rollback processing of a transaction, which is undecided due to a system failure, after system restart. The transaction control system includes: an orchestrator that generates a Try request for confirming whether to execute a transaction, the transaction being a series of processing generated by a request from a user, before causing a plurality of external servers to respectively execute the transaction; and a plurality of proxy devices provided correspondingly to the plurality of external servers, the plurality of proxy devices each respectively recording a flag indicating progress of a processing flow including generation of the Try request through decision of the transaction for corresponding one of undecided transaction in accordance with the progress. The plurality of proxy devices each determine whether to continue the processing of corresponding transaction among the undecided transaction based on the flag after restart.


