Database Transaction Conflict Graphs for Data Anomaly Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database systems face inefficiencies in transaction processing due to locking technologies that limit concurrency and dependency graph methods that require extensive traversal, leading to complex and incomplete data anomaly recognition.
Innovation Solution
A transaction processing method that determines conflicts between transactions based on read and write sets and version changes, using a conflict cycle graph to identify data anomalies and ensure data state consistency, thereby improving efficiency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If locking technology is used to recognize data anomalies, then data consistency is ensured, but transaction concurrency is limited, causing low transaction processing efficiency
Solution Approach 1:
The patent extracts the essential conflict detection logic from the locking mechanism and implements it independently through conflict detection graphs. Instead of using locks to prevent anomalies, the system detects conflicts after transaction execution and rolls back only when necessary, separating the detection function from the control function.
Solution Approach 2:
The patent introduces a conflict detection graph as an intermediary data structure that tracks transaction conflicts without requiring locks. This graph serves as a mediator between transaction execution and anomaly detection, allowing concurrent transactions to proceed while recording their interactions for later validation.
2Reliability
If dependency graph technology is used to confirm data anomalies by traversing concurrent transactions, then data consistency is verified, but transaction processing efficiency decreases due to extensive traversal requirements
Solution Approach 1:
The patent segments the dependency graph into smaller conflict detection graphs, where each graph tracks only the specific conflicts relevant to a transaction. This segmentation avoids the need to traverse the entire dependency graph, reducing the computational overhead while maintaining comprehensive anomaly detection.
Solution Approach 2:
The patent performs partial traversal of the dependency graph by only examining the portions relevant to each transaction's read and write sets. Instead of traversing the entire graph, the system focuses on specific conflict paths, reducing the traversal effort while still detecting all data anomalies.
3Reliability
If traditional conflict detection methods are used, then data anomalies are recognized, but the recognition process is incomplete and complex
Solution Approach 1:
The patent creates a universal conflict detection mechanism that handles multiple types of data anomalies (read-write conflicts, write-write conflicts, write-read conflicts) through a single unified approach. The conflict detection graph serves multiple functions: tracking conflicts, detecting anomalies, and determining rollback necessity, simplifying the overall recognition process.
Solution Approach 2:
The patent implements feedback loops where the conflict detection graph continuously updates transaction conflict information and provides real-time feedback on potential anomalies. This feedback mechanism allows the system to adjust transaction execution dynamically, ensuring complete anomaly recognition while reducing complexity through iterative refinement.
Data Source
Figure 1~2
Figure 3~5
Figure 6
AI summary
A transaction processing method and apparatus for a database system, and an electronic device, a computer readable storage medium, and a computer program product. The transaction processing method comprises: determining a concurrent transaction of a target transaction, the concurrent transaction and the target transaction comprising read and write operations acting on a same variable, and the target transaction being a transaction to be submitted (S501); obtaining a first intersection of a read set of the target transaction and a write set of the concurrent transaction, and obtaining a second intersection of a write set of the target transaction and a read set of the concurrent transaction; and when at least one of the first intersection and the second intersection is a non-empty data set and the target transaction conflicts with the concurrent transaction, determining a data exception type on the basis of the number of version changes of the same variable on which the target transaction and the concurrent transaction act and a target variable list, the target variable list comprising the same variable on which the target transaction and the concurrent transaction act (S502).