Global Epochs for Distributed Transaction Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Distributed transaction systems face challenges in maintaining consistency and recovery across multiple servers due to the complexity of managing transactions and failures, particularly in ensuring atomicity, consistency, isolation, and durability across a distributed environment.

Innovation Solution

The implementation of global epochs and distributed redo and undo logs allows for the propagation and logging of transactions throughout a cluster, enabling recovery from failures by maintaining local epochs on each node and using a stability coordinator to determine the global epochs for recovery, ensuring that the cluster state can be accurately restored after a failure or eviction.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If multi-phase commit protocols are used to manage distributed transactions, then transaction consistency and atomicity are improved, but system complexity and coordination overhead increase

Engineering Contradiction:
Improvetransaction consistencyVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system segments the distributed transaction management into per-node epoch tracking and global epoch coordination. Each node maintains its own local epoch for tracking transactions, while a global epoch coordinator manages the overall transaction state across all nodes. This segmentation reduces the complexity of coordinating transactions across multiple nodes while maintaining consistency through the epoch-based protocol.

Inventive Principle:
Principle #1Segmentation

2Reliability

If transactions are monitored across multiple servers, then durability and isolation are improved, but coordination overhead and failure recovery complexity increase

Engineering Contradiction:
Improvetransaction durabilityVSAvoidcoordination overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The global epoch coordinator acts as an intermediary that manages the coordination between multiple servers. It receives epoch information from individual nodes, determines when transactions can be committed or rolled back, and coordinates the overall transaction state. This intermediary approach reduces the complexity of direct multi-server coordination while ensuring durability through centralized epoch management.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If local epochs are updated monotonically on each node, then transaction ordering and consistency are improved, but system performance and throughput may be reduced

Engineering Contradiction:
Improvetransaction orderingVSAvoidsystem throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

Instead of continuously updating epochs, the system uses periodic epoch advancement driven by transaction completion events. Nodes advance their local epochs periodically when transactions are committed or rolled back, rather than continuously monitoring and updating. This periodic approach maintains transaction ordering while reducing the overhead of constant epoch updates, thereby improving throughput.

Inventive Principle:
Principle #19Periodic action

Data Source

PatentUS8103643B2System and method for performing distributed transactions using global epochs
Publication Date: 2012.01.24 CRAY INC
  • US8103643B2 patent drawing
  • US8103643B2 patent drawing
  • US8103643B2 patent drawing

AI summary

A method for performing distributed transactions of a cluster. The method includes, in response to a lock request including a first epoch from a first node, setting a local epoch to a maximum of the first epoch and the local epoch, sending a first lock including the local epoch to the first node, and in response to a conflicting lock request including a second epoch from a second node, setting the local epoch to a maximum of the second epoch and the local epoch, where the conflicting lock request is delayed until after the first lock is released. The method further includes, in response to a reintegration request including a third epoch from the first node, setting the local epoch to a maximum of the third epoch and the local epoch and performing a reintegration based on the reintegration request, where the reintegration is logged using the local epoch.