Transaction Control Block Index for Database Timestamp Management

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems face inefficiencies in managing concurrent transactions, particularly in ensuring consistent views and allowing in-flight transactions to read their own writes, which are not visible to other transactions, leading to complex code and performance issues.

Innovation Solution

The implementation of a transaction control block index that assigns temporary and final timestamps to records, using a commit timestamp generator, and a visibility function to determine visible records, allowing in-flight transactions to access their own writes without requiring shared structures or re-stamping transactions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If timestamp-based multi-version concurrency control is used to ensure consistent views for concurrent transactions, then transaction consistency is improved, but memory consumption and execution time increase due to the need to track and manage multiple versions and timestamps for each record

Engineering Contradiction:
Improvetransaction consistencyVSAvoidexecution time
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent extracts the timestamp management functionality from the main transaction processing path by introducing a dedicated commit timestamp generator that operates independently. This generator is selectively locked only when needed to issue new timestamps, allowing most transaction operations to proceed without timestamp-related blocking. The extraction separates the critical path (transaction execution) from the non-critical path (timestamp generation), thereby reducing execution time while maintaining consistency guarantees.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements preliminary action by pre-allocating and pre-managing the commit timestamp generator before transactions need to access it. The timestamp generator is ready and waiting in a controlled state, so when a transaction needs a timestamp, it can acquire it efficiently without complex runtime negotiations or locking protocols. This preliminary preparation eliminates runtime overhead and reduces execution time for timestamp-based consistency checks.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If complex visibility determination functions are implemented to allow in-flight transactions to read their own writes, then transaction functionality is improved, but code complexity and resource management overhead increase

Engineering Contradiction:
Improvetransaction functionalityVSAvoidcode complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements self-service by enabling in-flight transactions to automatically read their own writes through the transaction control block index without requiring complex visibility determination functions. Each transaction can directly access its own uncommitted writes through its assigned TCB index, eliminating the need for sophisticated visibility checking logic. This self-service mechanism simplifies the code while maintaining full transaction functionality, as transactions manage their own visibility needs without external intervention.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent introduces the transaction control block index as an intermediary structure that mediates between transactions and the data they access. This index acts as a lookup table that maps transaction IDs to their control blocks, providing direct access paths for visibility determination. Instead of implementing complex visibility functions that analyze multiple timestamps and transaction states, the system uses this simple intermediary index to provide O(1) access to transaction-specific information, dramatically reducing code complexity while preserving functionality.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If shared structures are used to manage commit timestamps for multiple transactions, then timestamp management is improved, but the need for locking and synchronization increases execution time and resource costs

Engineering Contradiction:
Improvetimestamp managementVSAvoidlocking overhead
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the timestamp management system by creating a dedicated commit timestamp generator for each transaction through the transaction control block index. Instead of using a single shared timestamp counter that requires locking, each transaction has its own logical timestamp space accessible via its TCB index. This segmentation eliminates the need for mutual exclusion mechanisms, as transactions operate in independent timestamp namespaces. The segmentation maintains timestamp management reliability while eliminating locking overhead that would otherwise slow down transaction execution.

Inventive Principle:
Principle #1Segmentation

4Device complexity

If in-flight transactions cannot read their own writes due to visibility restrictions, then consistency control is simplified, but transaction performance and usability deteriorate

Engineering Contradiction:
Improveconsistency controlVSAvoidtransaction performance
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The patent applies local quality by implementing different visibility rules for different transaction contexts. Specifically, in-flight transactions are granted local visibility to their own writes through the transaction control block index, while other transactions continue to see only committed data. This localized visibility optimization allows each transaction to efficiently read its own intermediate states without requiring global changes to the consistency control mechanism. The local quality approach maintains simplified consistency control while dramatically improving transaction performance and usability for operations that need to read their own uncommitted changes.

Inventive Principle:
Principle #3Local quality

Data Source

PatentEP3026581B1Database system with transaction control block index
Publication Date: 2018.12.05 SAP SE
  • EP3026581B1 patent drawingFigure 1
  • EP3026581B1 patent drawingFigure 2
  • EP3026581B1 patent drawingFigure 3

AI summary

A plurality of transactions is handled in a database. Each transaction includes a plurality of operations on at least one record in the database with at least two of the transactions being handled concurrently. Thereafter, a temporary timestamp is assigned to each record. The temporary timestamp are based, at least in part, on the corresponding transaction. Further, a final timestamp is assigned to each record with a commit operation. It can later be determined, using a visibility function and based on the assigned temporary timestamps and final timestamps, which of the records are visible in a consistent view for a first transaction. Based on such determination, access can be provided to those records determined to be visible to be accessed to the first transaction.