Database Lock Handling with Modification Flag Check
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In database systems, transactions queuing for access to locked data often experience unnecessary retries due to data changes made by the previous transaction, leading to increased latency and resource wastage, as they attempt to execute with outdated snapshots, resulting in execution failures and extra processing.
Innovation Solution
Implementing a dynamic transaction processing approach where the database manager checks for data changes made by the previous transaction using a flag system before allowing the next transaction to execute, ensuring data consistency and reducing unnecessary retries by refreshing snapshots or aborting transactions as needed based on isolation levels.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a lock is issued to preserve data consistency, then data integrity is maintained, but transaction latency increases due to waiting transactions
Solution Approach 1:
The patent applies preliminary action by checking whether the previous transaction modified the data before allowing the next transaction to execute. This is done by setting a flag when a lock is issued and checking this flag before transaction execution. If the flag indicates no modification occurred, the transaction can proceed immediately without waiting, thus reducing latency while maintaining consistency when modifications did occur.
2Productivity
If transactions retry execution after lock release, then data access is ensured, but unnecessary processing occurs when data unchanged
Solution Approach 1:
The patent performs a preliminary check using a flag system before transaction execution. When a lock is issued, a flag is set to indicate whether the data was modified. Before the next transaction executes, this flag is checked. If the flag shows no modification, the transaction is prevented from executing unnecessarily, thus avoiding waste of processing resources while ensuring execution when needed.
Solution Approach 2:
The patent implements feedback by using a flag that provides information about whether the previous transaction modified the data. This feedback mechanism allows the system to make informed decisions about whether to allow the next transaction to execute. The flag acts as a feedback signal that prevents unnecessary retries when data remains unchanged, thereby reducing energy consumption and processing overhead.
3Speed
If transactions execute with outdated snapshots, then quick access is achieved, but execution failures occur due to data changes
Solution Approach 1:
The patent applies preliminary action by checking the modification flag before allowing transaction execution with a snapshot. This preliminary check ensures that transactions only execute with outdated snapshots when the data has not been modified, preventing execution failures. The flag check occurs before execution, allowing the system to maintain speed when safe while ensuring reliability when data changes have occurred.
Data Source
AI summary
Disclosed herein are system, method, and computer program product embodiments for performing database processing after a lock condition. An embodiment operates by receiving a release of a lock on data of a database. It is determined whether the data was modified by a processing of a first transaction associated with the first request. The lock is provided to a second transaction associated with a second request to access the data. If the first transaction did not modify the data, a second transaction associated with the second request is retried without refreshing a snapshot of the data. If the first transaction modified the data, the snapshot of the data is refreshed before the second transaction is retried.