Distributed Transaction Manager Isolation for Cluster Reliability
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems for global transactions in computer systems face challenges in ensuring atomicity and recovery, particularly when the transaction manager fails, leading to application hangs and non-recoverable transactions due to locked resources and indeterminate states.
Innovation Solution
A distributed transaction management system where each application server has its own transaction manager instance, with shared highly available storage for transaction logs, allowing for recovery of in-flight transactions across nodes in case of failure, and a Domain Administration Server or peer monitoring for failure detection and recovery.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single centralized transaction manager is used to coordinate global transactions across multiple backend systems, then transaction coordination and atomicity can be ensured, but the system becomes vulnerable to single points of failure and cannot provide recovery when the transaction manager fails
Solution Approach 1:
The patent divides the single centralized transaction manager into multiple distributed transaction manager instances, each capable of coordinating transactions independently. This segmentation eliminates the single point of failure while maintaining transaction coordination capabilities across the distributed system.
Solution Approach 2:
The patent introduces a transaction log as an intermediary component that stores transaction state information independently of any single transaction manager instance. This mediator enables recovery by allowing any transaction manager instance to retrieve and continue coordinating transactions even after failures.
2Reliability
If a robust two-phase commit protocol is implemented to allow recovery from participant failures, then transaction atomicity can be maintained, but the protocol cannot provide recovery when the transaction manager itself fails
Solution Approach 1:
The patent performs preliminary actions by logging transaction state information to persistent storage before transaction completion. This preliminary logging enables rapid recovery without requiring time-consuming reconstruction of transaction state after failures.
Solution Approach 2:
The patent creates copies of transaction state information in the transaction log that can be accessed by any transaction manager instance. This copying mechanism allows failed transactions to be recovered by different instances without loss of time, as the state information is immediately available.
3Reliability
If transaction logs are maintained locally on each application server node, then node independence can be achieved, but logs become inaccessible when the node fails
Solution Approach 1:
The patent implements a shared transaction log storage system that serves multiple functions: it stores transaction state for active transactions, enables recovery for failed transactions, and provides accessibility to any transaction manager instance in the cluster. This universal storage architecture ensures log availability regardless of which node fails.
4Productivity
If a centralized transaction manager coordinates all transactions in the cluster, then consistent transaction management can be achieved, but performance bottlenecks and scalability issues occur when multiple application server nodes are included
Solution Approach 1:
The patent segments the transaction management function across multiple independent instances distributed throughout the cluster. Each instance handles transactions locally, eliminating the centralized bottleneck and improving throughput while maintaining reliability through distribution.
Solution Approach 2:
The patent transitions from a single-dimension centralized architecture to a multi-dimensional distributed architecture where transaction managers are spread across multiple nodes in the cluster. This dimensional change enables parallel transaction processing and eliminates single points of failure.
Data Source
AI summary
Various embodiments of a cluster of application servers in a networked computer system in which each application server includes a separate transaction manager instance are disclosed. In one embodiment, a separate transaction manager instance may be used to coordinate transactions initiated by an application component executing in process with the application server for a node of a cluster. If each transaction manager instance manages only transactions initiated within its own application server, then the loss of a single transaction manager instance may have no detrimental effect on transactions initiated in other nodes of the cluster. Further, if each transaction manager instance maintains its transaction logs in highly available memory accessible to all nodes of the cluster, in flight transactions of a failed node may be recovered by an instance in a different node.