Slave Server Transaction ID Buffering for Distributed Database Efficiency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In multi-version concurrency control (MVCC) databases, the overhead of requesting and responding to individual transaction identifiers for each write transaction across slave and master servers leads to resource consumption and processing slowdowns due to the need for multiple round trips between servers.

Innovation Solution

Implementing a local transaction coordinator on slave servers to buffer and manage multiple transaction identifiers, requesting batches from a global transaction coordinator only when necessary, reducing the need for frequent communication with the master server.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If individual transaction identifier requests are processed for each write transaction on slave servers, then transaction identifier management is centralized and consistent, but processing overhead and resource consumption increase due to multiple round trips between servers

Engineering Contradiction:
Improvetransaction identifier management consistencyVSAvoiddatabase processing speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system pre-allocates batches of transaction identifiers to slave servers before they are needed. The master server maintains a pool of pre-generated transaction identifiers that can be quickly distributed to slave servers, eliminating the need for real-time generation and reducing round-trip communication overhead while maintaining centralized control

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The transaction identifier management is segmented into batch allocations rather than individual requests. Slave servers receive batches of transaction identifiers that they can use locally for multiple write transactions, reducing the frequency of communication with the master server while maintaining consistency through structured batch management

Inventive Principle:
Principle #1Segmentation

2Reliability

If slave servers frequently communicate with the master server for transaction identifiers, then centralized transaction coordination is maintained, but communication latency and resource consumption increase

Engineering Contradiction:
Improvecentralized transaction coordinationVSAvoidcommunication latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Transaction identifiers are pre-generated and buffered on the master server in batches. When slave servers need identifiers, they receive pre-prepared batches rather than requesting individual identifiers, significantly reducing communication latency while maintaining centralized coordination through the master server's control over identifier allocation

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

A transaction identifier buffer acts as an intermediary between the master server and slave servers. This buffer stores pre-allocated transaction identifiers locally on slave servers, reducing the need for frequent direct communication with the master server while maintaining the centralized coordination model

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2738695B1Slave side transaction ID buffering for efficient distributed transaction management
Publication Date: 2018.08.22 SAP SE
  • EP2738695B1 patent drawingFigure 1
  • EP2738695B1 patent drawingFigure 2
  • EP2738695B1 patent drawingFigure 3

AI summary

Methods, systems and computer-readable storage mediums encoded with computer programs executed by one or more processors for providing a compressed representation of a transaction token are disclosed. In an embodiment, upon a receipt of a request for a write transaction at a slave server it is determined whether there exists an unassigned transaction identifier (TID) stored locally at the slave server as provided by a master server to the slave server prior to the receipt of the write request by the slave server. If there exists an unassigned TID at the slave server, the slave server is configured to assign the unassigned TID to the write transaction, otherwise the slave server is configured to request a plurality of unassigned TIDs from the master server, receive the plurality of unassigned TIDs, and assign one of the received unassigned TIDs to the write transaction. The write transaction is processed.