Transaction Visibility Control for Dirty Read Prevention
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Concurrent transactions in databases can cause dirty read problems, which violate the isolation level of transactions, particularly in the Read Commit scenario.
Innovation Solution
Implement a method and device for controlling transaction concurrency by using record header data that includes record lock information, state information, creation version number, and deletion version number to determine the visibility of a target record to a transaction, ensuring that transactions are only read after they are committed, thereby maintaining the Read Commit isolation level and preventing dirty reads.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If concurrent transactions are allowed in database operations, then transaction processing speed and system throughput are improved, but dirty read problems occur violating transaction isolation level
Solution Approach 1:
The patent introduces a transaction registration list as an intermediary mechanism between concurrent transactions and database records. This list acts as a mediator that tracks which transactions are currently active and have not yet committed. When a read operation occurs, the system checks the transaction registration list to determine if the target record was created by an uncommitted transaction, thereby preventing dirty reads while allowing concurrent transaction processing to proceed.
Solution Approach 2:
The patent implements preliminary action by requiring transactions to register themselves in the transaction registration list before they begin their operations. This preliminary registration allows the system to proactively identify and block potential dirty read scenarios before they occur, rather than detecting and correcting them after the fact. The read version number is also preliminarily set based on the current transaction context.
2Reliability
If strict transaction isolation is enforced to prevent dirty reads, then data consistency is maintained, but transaction concurrency and system throughput deteriorate
Solution Approach 1:
The patent applies local quality by implementing fine-grained control over transaction isolation at the record level rather than applying blanket isolation to all transactions. The system checks the transaction registration list specifically for the creator of each target record, allowing reads from records created by committed transactions while blocking reads from records created by uncommitted transactions. This localized approach maintains data consistency where needed while allowing concurrency elsewhere.
Solution Approach 2:
The patent utilizes parameter changes by dynamically adjusting the read version number based on the transaction context. When a transaction reads a record, the system checks if the record's creation version matches the current transaction's read version. This parameter-based control mechanism allows the system to maintain isolation guarantees while permitting high concurrency, as each transaction operates with its own version context.
3Reliability
If transaction registration and version checking mechanisms are implemented, then dirty read prevention is achieved, but system complexity and overhead increase
Solution Approach 1:
The patent implements self-service by making transactions responsible for their own registration and version tracking. Each transaction automatically registers itself in the transaction registration list and manages its own read version number. This self-service approach reduces the need for complex centralized control mechanisms, as the system leverages the transactions' own metadata to enforce isolation guarantees.
Solution Approach 2:
The patent uses copying by maintaining a lightweight transaction registration list that contains only essential information (transaction IDs and commit status) rather than duplicating full transaction states. This copied metadata structure provides the necessary information for dirty read prevention while keeping the overhead minimal compared to full transaction state replication.
Data Source
AI summary
A method for controlling transaction concurrency implemented in an electronic device includes: obtaining a read operation for a target record; in response to the read operation, obtaining record header data of the target record; in response that the target record is in a valid state according to the state information, the target record is not deleted according to the record lock information, the deletion version number is null, and the creation version number is not equal to the unique identifier of the first transaction, determining whether the creation version number is in a transaction registration list; when the creation version number is not in the transaction registration list, reading the target record; and when the creation version number is in the transaction registration list, determining that the target record is unreadable to the first transaction.