Independent Recovery Subsystem for Transaction Processing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional transaction processing systems are not designed to handle the dynamic scalability and disk availability challenges of cloud computing environments, particularly in elastic infrastructure where application nodes can be added or removed, leading to issues with pending transactions and recovery processes.
Innovation Solution
A distributed transaction processing system comprising separate transaction processing, recovery, and resource subsystems, where the recovery subsystem can operate independently to clean up pending transactions and perform recovery actions without relying on the availability of the transaction processing subsystem, using a DBMS log for logging and storage of transaction records.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional transaction processing systems are deployed in elastic cloud infrastructure, then dynamic scalability is achieved, but reliability of transaction completion deteriorates due to node failures and disk unavailability
Solution Approach 1:
The system separates the transaction processing function into two independent subsystems: the TP subsystem that executes transactions and the recovery subsystem that manages transaction completion. This segmentation allows the recovery subsystem to independently track and complete transactions even when TP subsystem nodes fail, resolving the contradiction between scalability and reliability.
Solution Approach 2:
The recovery subsystem performs preliminary actions by continuously receiving logging information from TP subsystems and maintaining a record of pending transactions. When failures occur, the recovery subsystem can immediately act on this pre-collected information to complete or rollback transactions, ensuring reliability without compromising scalability.
2Productivity
If application nodes are dynamically added or removed for elasticity, then productivity is improved, but data consistency deteriorates due to pending transactions from killed nodes
Solution Approach 1:
The recovery subsystem acts as an intermediary between TP subsystems and resource subsystems. It receives logging information from TP subsystems and performs recovery actions on resource subsystems, mediating the interaction to ensure data consistency even when TP nodes are dynamically added or removed.
Solution Approach 2:
The system implements feedback through logging information that continuously flows from TP subsystems to the recovery subsystem. This feedback mechanism allows the recovery subsystem to monitor pending transactions and take corrective actions to maintain data consistency during dynamic node changes.
3Device complexity
If recovery subsystem depends on TP subsystem availability, then device complexity is reduced, but reliability deteriorates when TP subsystems are unavailable
Solution Approach 1:
The recovery capability is extracted from the TP subsystem and placed in a separate, independent recovery subsystem. This extraction allows the recovery subsystem to operate independently without depending on TP subsystem availability, resolving the contradiction between simplicity and reliability.
4Reliability
If separate recovery server is used, then reliability is improved, but device complexity increases due to additional infrastructure
Solution Approach 1:
The recovery subsystem is designed with multi-functionality, handling multiple recovery operations and interacting with multiple TP subsystems and resource subsystems through a unified interface. This universality justifies the additional infrastructure by providing comprehensive recovery capabilities across the entire distributed system.
Data Source
AI summary
A transaction processing system comprises a transaction processing (TP) subsystem (11) executed on a TP server (21), a recovery subsystem (13), executed on a recovery server (23) and one or more resource subsystems (12) executed on one or more resource servers (22). The TP subsystems (11) are configured to access the one or more resource subsystems (12), wherein the TP server (21) is not the same server as the recovery server (23), andwherein the recovery subsystem (13) itself, or a DBMS log that the recovery subsystem is configured to read from and to write to, is configured to clean up pending transactions created in the transaction processing system, in the event of failures,wherein the recovery subsystem (13) is configured to receive logging information from the one or more TP subsystems (11), and to store logging information in transaction log records in a recovery storage (25);the recovery subsystem (13) is configured to access the one or more resource subsystems (12) to perform, in the one or more resource subsystems (12), recovery actions in the event of failures, based on the logging information, andthe recovery subsystem (13) is able to run without any functionality of the one or more TP subsystems (11) being available.