Per-Table Timestamp Cache Invalidation for Database Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems face inefficiencies in cache invalidation mechanisms, particularly when dealing with transactions that modify or delete table entries, leading to unnecessary cache invalidation and reduced performance.

Innovation Solution

Implementing a system where each source table and cached entity has its own timestamp, allowing for separate invalidation of cached entities without affecting others, and using a table update tracker to manage and invalidate timestamps efficiently across cache nodes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a transaction modifies or deletes table entries, then data consistency is maintained through cache invalidation, but unnecessary cache invalidation occurs reducing performance

Engineering Contradiction:
Improvedata consistencyVSAvoidquery performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the cache invalidation process by introducing per-table timestamps instead of global invalidation. Each table maintains its own timestamp, and cache nodes only invalidate entries when their specific table's timestamp changes. This segmentation eliminates unnecessary invalidations of unrelated cache entries while maintaining data consistency for modified tables.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent changes the parameter tracking approach from binary valid/invalid states to timestamp-based version tracking. By using timestamps that increment with each table modification, the system can precisely determine which cache entries need invalidation based on timestamp comparison, rather than broadly invalidating all cached data during transactions.

Inventive Principle:
Principle #35Parameter changes

2Productivity

If per-table timestamps are implemented, then cache efficiency improves by eliminating unnecessary invalidations, but system complexity increases

Engineering Contradiction:
Improvecache efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements self-service through automatic timestamp management. The database system automatically increments and maintains timestamps for each table modification without manual intervention. Cache nodes automatically compare their cached timestamps with current table timestamps and perform selective invalidation, eliminating the need for complex manual cache management while improving efficiency.

Inventive Principle:
Principle #25Self-service

3Reliability

If cache nodes query table timestamps frequently, then cache validity is ensured, but computational overhead increases

Engineering Contradiction:
Improvecache validityVSAvoidcomputational overhead
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent applies preliminary action by having cache nodes proactively query table timestamps before performing read operations. By checking timestamp validity in advance, the system avoids computational waste on invalid cache entries and ensures cache validity is maintained with minimal overhead during actual query execution.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS10877956B2Transactional cache invalidation for inter-node caching
Publication Date: 2020.12.29 SAP SE
  • US10877956B2 patent drawing
  • US10877956B2 patent drawing
  • US10877956B2 patent drawing

AI summary

Disclosed herein are system, method, and computer program product embodiments for efficiently providing transaction-consistent snapshots of data stored in or associated with a database stored within a database management system. An embodiment operates by receiving, at a source database, an update request to update a table at the source database and transmitting a message to a cache node to invalidate a copy of a table time stamp associated with the table, where the copy of the table time stamp is stored at the cache node. The embodiment continues by updating the table at the source database based on the update request.