Distributed Transaction Group Rollback for Microservice Data Consistency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In microservice architecture (MSA) environments, when an error occurs in a transaction, previously processed transactions cannot be rolled back, leading to data inconsistency across transactions. Additionally, centralized management methods can lead to system paralysis under heavy loads and are limited to homogeneous DBMS systems.
Innovation Solution
A method and apparatus for processing a series of database transaction groups, where transactions are recorded with a transaction group ID, allowing for sequential rollback of transactions in case of errors. This approach ensures data consistency across transactions and allows for changes in transaction logic without interrupting applications, supporting heterogeneous DBMS systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a centralized management method is used to manage transactions for each application, then transaction consistency can be improved, but the system may be paralyzed when the central controller is heavily loaded
Solution Approach 1:
The patent divides the centralized transaction management into distributed components. Each application independently manages its own transactions using local database rollback capabilities, eliminating the single point of failure at the central controller while maintaining transaction consistency through application-level coordination.
Solution Approach 2:
Each application is equipped with its own transaction monitoring and rollback functionality. When an error occurs in one application's transaction, the application itself can detect the error and initiate rollback operations without requiring intervention from a central controller, enabling autonomous error handling.
2Reliability
If a centralized management method is used to manage transactions, then transaction consistency can be improved, but the method can be applied only to the same database management system
Solution Approach 1:
The patent employs a universal transaction management approach where each application uses standard database rollback mechanisms that are compatible with multiple DBMS systems. The transaction monitoring and rollback logic is implemented in a way that works across different database technologies, making the system adaptable to heterogeneous environments.
3Reliability
If each application is equipped with a function for monitoring errors in transactions and rolling back errors, then data consistency can be improved, but the costs of developing applications may increase
Solution Approach 1:
The transaction monitoring and rollback functions are implemented as self-service capabilities within each application. Applications independently monitor their own transactions and execute rollbacks when errors occur, eliminating the need for complex external monitoring systems or centralized management overhead.
Solution Approach 2:
The patent incorporates transaction monitoring and rollback logic during the application development phase, building these capabilities into the application structure itself. This preliminary integration ensures that error handling is built-in from the start, avoiding the need for additional post-development complexity.
4Reliability
If there is a change in the additional function for monitoring transactions in an application, then transaction monitoring can be improved, but the entire application must be stopped
Solution Approach 1:
The transaction monitoring and rollback functions are designed as dynamic, modifiable components that can be updated without requiring application restarts. The system allows for flexible configuration changes in monitoring parameters and rollback strategies while the application remains running, enabling continuous improvement without service interruption.
Data Source
AI summary
A method for processing a series of database transactions according to an embodiment includes recording a first transaction requested to a first database by a first application, among the plurality of applications, in association with a transaction group ID, recording a second transaction requested to a second database by a second application called by the first application, among the plurality of applications, in association with the transaction group ID, rolling back the second transaction targeted to the second database in response to a determination that an error has occurred during processing of the second transaction, identifying the first transaction based on the transaction group ID and rolling back the first transaction targeted to the first database.