Distributed Cache Consistency via Two-Phase Commit

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In distributed client/server systems, maintaining strong consistency between replicated cache files across multiple processing nodes while ensuring quasi-real-time availability and scalability is challenging, as existing solutions often compromise on consistency and availability due to the CAP theorem constraints.

Innovation Solution

A method involving a 2-phase commit process where a master server generates and stores a new version of a replicated file, notifies all slave nodes, and only updates the master database after all slave nodes acknowledge successful preloading, ensuring that all nodes are synchronized before committing the update, thus maintaining strong consistency and availability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If distributed cache files are implemented to improve scalability and availability, then system scalability and availability are enhanced, but consistency between replicated files across slave nodes deteriorates

Engineering Contradiction:
Improvesystem scalabilityVSAvoidconsistency between replicated files
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system performs preliminary preloading of replicated files to a shared file system before committing updates to the master database. This preliminary action ensures that all slave nodes have the updated files ready before the commit occurs, thereby maintaining consistency across the distributed system while preserving scalability and availability benefits.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

A shared file system acts as an intermediary between the master database and slave nodes. This intermediary layer enables consistent distribution of replicated files to all slave nodes without requiring direct communication between the master database and each slave node, thus maintaining consistency while preserving system scalability.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If distributed cache files are implemented to improve availability, then query response availability is enhanced, but consistency between replicated files across slave nodes deteriorates

Engineering Contradiction:
Improvequery response availabilityVSAvoidconsistency between replicated files
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system performs preliminary preloading of replicated files to a shared file system before committing updates to the master database. This ensures that slave nodes have updated files ready, maintaining consistency while preserving query response availability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The shared file system serves as an intermediary that enables consistent file distribution to slave nodes, ensuring they all receive the same updated replicated files while maintaining high availability for query responses.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Speed

If updates are committed immediately to master database, then update speed is improved, but consistency between master database and slave nodes deteriorates

Engineering Contradiction:
Improveupdate speedVSAvoidconsistency between master database and slave nodes
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The system performs preliminary preloading of replicated files to the shared file system before committing updates to the master database. This preliminary action ensures consistency is established before the commit occurs, while the overall process remains efficient.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system uses a two-phase commit process with feedback mechanisms where slave nodes acknowledge successful preloading before the master database commit proceeds. This feedback ensures consistency is verified before finalizing the update, maintaining both speed and reliability.

Inventive Principle:
Principle #23Feedback

4Reliability

If two-phase commit process is implemented to improve consistency, then strong consistency between nodes is achieved, but update complexity increases

Engineering Contradiction:
Improvestrong consistency between nodesVSAvoidupdate process complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The update process is segmented into two distinct phases: preloading phase and commit phase. This segmentation allows each phase to be optimized independently and makes the complex two-phase commit process more manageable and implementable through clear separation of concerns.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The shared file system acts as an intermediary that simplifies the two-phase commit process by providing a centralized location for preloaded files, reducing the complexity of direct peer-to-peer coordination between master and slave nodes.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2555129B1Method and system to maintain strong consistency of distributed replicated contents in a client/server system
Publication Date: 2019.02.06 AMADEUS SAS
  • EP2555129B1 patent drawingFigure 1~2
  • EP2555129B1 patent drawingFigure 3
  • EP2555129B1 patent drawingFigure 4a

AI summary

A method and a system for maintaining consistency of replicated files distributed over a plurality of independent processing slave nodes (210, 210', 210") part of an application tier of a multi-tier client/server data processing system are described. The replicated files are distributed from a master node of a master tier. Upon reception of an update request (142) to update a master database a new version of a replicated file is first generated and stored in a shared file system (160). Then, a notification of availability of the new version is forwarded to a synchronizing slave node and, from there, broadcasted to all slave nodes (210, 210', 210") . Each slave node preloads the new version (150) of the replicated file from the shared file system (160) and acknowledges successful completion. Upon reception of all acknowledgments in the synchronization slave node a notification of preloading achievement is forwarded to the master server (112) which updates the master database thus committing the use of the new version by the data processing system. The commitment is further forwarded to the synchronizing slave node which commits in turn the use of the new version (150) of the replicated file in a slave database aimed at keeping track of all replicated file versions for all slave nodes (210, 210', 210") . Upon reception of a notification of commitment of all slave nodes (210, 210', 210") , the master server (112) acknowledges completion of the update in response to the received update request (142).