Client-Side Transaction Token Caching for Distributed Database Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Distributed database systems face challenges in managing transactions across multiple nodes, particularly in maintaining data consistency and concurrency control, as existing methods like snapshot isolation struggle with efficient version management and transaction token handling.

Innovation Solution

Implementing a system with multi-version concurrency control, where each transaction is assigned a transaction token for snapshot isolation, allowing database nodes to manage multiple versions of data and coordinate transactions across nodes, enabling efficient query execution and commit operations without requiring continuous token requests from a coordinator node.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If snapshot isolation with transaction tokens is implemented in distributed database systems, then data consistency and concurrency control are improved, but the overhead of token management and coordination increases

Engineering Contradiction:
Improvedata consistencyVSAvoidtoken management overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The client device caches the transaction token before executing subsequent read queries, performing the token acquisition action in advance. This preliminary caching eliminates the need for repeated token requests during the transaction, reducing coordination overhead while maintaining snapshot isolation guarantees for consistent reads across multiple queries.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The client device autonomously manages the transaction token by caching it locally and reusing it for multiple read queries without requiring continuous coordination with the database node. This self-service approach to token management reduces the burden on the database system while maintaining data consistency.

Inventive Principle:
Principle #25Self-service

2Reliability

If continuous token requests are made from coordinator node for each query, then data consistency is maintained, but communication overhead and query execution time increase

Engineering Contradiction:
Improvedata consistencyVSAvoidquery execution time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The transaction token is obtained and cached in advance before executing multiple read queries. This preliminary action eliminates the need for repeated communication rounds between the client and coordinator node, significantly reducing query execution time while maintaining consistency through the cached token's snapshot isolation guarantees.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The cached transaction token enables continuous execution of multiple read queries without interruption for token re-requests. This continuity of useful action maintains data consistency across all queries in the transaction while eliminating communication overhead between queries, improving overall query execution efficiency.

Inventive Principle:
Principle #20Continuity of useful action

3Productivity

If multiple versions of data are maintained for snapshot isolation, then concurrency control is improved, but storage requirements and version management complexity increase

Engineering Contradiction:
Improveconcurrency control efficiencyVSAvoiddata version storage
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The patent extracts only the essential transaction token (containing the snapshot timestamp) from the full data versions and caches it at the client device. This extraction approach allows the client to reference the appropriate data version without storing complete copies of all versions, reducing storage requirements while maintaining the ability to observe consistent snapshots across multiple queries.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentEP2653986B1Client-side caching of a database transaction token.
Publication Date: 2017.06.14 SAP SE
  • EP2653986B1 patent drawingFigure 1
  • EP2653986B1 patent drawingFigure 2
  • EP2653986B1 patent drawingFigure 3

AI summary

A system includes reception of a first query of a first transaction from a client device at a first database node of a database instance comprising two or more database nodes, request of a first transaction token associated with the first transaction from a second database node of the two or more database nodes, reception of the first transaction token from the second database node at the first database node, execution of the first query at the first database node to generate first results, and transmission of the first results and the first transaction token from the first database node to the client device.