Database Timestamps for Rollback and Merge
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database management systems (DBMS) face inefficiencies in processing transactions due to high processor load, resource consumption, and complexity in maintaining ACID properties, especially during rollback and merging of independently updated database instances, leading to cascading resets and inconsistencies.
Innovation Solution
A DBMS that uses real-time timestamps to store data records, allowing for efficient rollback and merging by creating copies of data records with updated timestamps, thereby reducing the need for extensive transaction logs and enabling logical or physical resets without blocking parallel operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If transactional DBMS creates extensive histories of all database operations to enable rollbacks, then database consistency can be restored, but RAM and disk space consumption increases significantly
Solution Approach 1:
The patent extracts only the essential temporal information (timestamps) from the transaction history, storing them directly with the data records rather than maintaining separate extensive transaction logs. This allows rollback capability while minimizing storage requirements.
Solution Approach 2:
Instead of storing complete transaction histories, the system creates simplified copies containing only the necessary timestamp information for each data record modification, enabling recovery without the overhead of full transaction logging.
2Reliability
If transactional DBMS monitors compliance with ACID properties for each transaction, then database integrity is maintained, but processor load increases significantly
Solution Approach 1:
The patent segments the ACID compliance monitoring into simpler, more manageable checks that operate on individual data records with timestamps rather than requiring comprehensive transaction-level validation, reducing processor overhead while maintaining integrity.
Solution Approach 2:
The system uses self-service mechanisms where timestamps automatically provide the necessary chronological ordering and consistency information, eliminating the need for complex active monitoring and validation logic that would increase processor load.
3Reliability
If transactional DBMS prevents transactions from being executed due to another transaction already in progress, then ACID compliance is ensured, but execution speed decreases due to blocking
Solution Approach 1:
The patent introduces dynamic timestamp-based validation that allows multiple transactions to proceed concurrently without blocking, with consistency ensured through temporal ordering of operations based on their timestamps rather than sequential execution control.
4Reliability
If transactional DBMS creates copies of data records with updated timestamps, then rollback capability is maintained, but device complexity increases
Solution Approach 1:
The patent applies local quality by adding timestamp information specifically to individual data records that require rollback capability, rather than implementing a complex global version control system. This localized approach maintains simplicity while providing the necessary recovery functionality.
Data Source
Figure 1~2b
Figure 3~4
Figure 5
AI summary
The invention relates to a first data processing system (156) with a first DBMS (160) and a first real-time clock (168). The first DBMS comprises a first database (102) with a plurality of data sets (DR1-DR7). Each data set includes multiple field values and timestamps (t1, t2, t3, t33) which are stored in a linked manner with the field values. The first DBMS is configured to: − receive (304) a first write command to change a field value of one of the data sets of the first database; − in response to receiving the first write command: o receive (306) a current time from the first real-time clock; and o store (308) a copy of the data set, the field value of which is to be changed by the write command, into the first database, wherein the data set copy has a field value which has been changed in accordance with the write command instead of the previous field value, said changed field value being stored in a linked manner with a timestamp which specifies the current time received from the first real-time clock, wherein one or more of the other field values of the data set copy are stored in a linked manner with a respective timestamp which specifies a different time, or all other field values of the data set copy are stored in a linked manner with a respective timestamp which specifies the time determined by the first real-time clock; and − the first DBMS includes an import interface (174) which is designed to import (310) additional data sets, each of which consists of multiple field values and timestamps linked with the field values, into the first database.