Dynamic Action Queuing Engine for Partitioned Database Lock Chains
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In highly partitioned databases, existing lock chain management mechanisms, such as the naïve model, result in delays due to unnecessary queue acquisitions on unused partitions, leading to inefficiencies in concurrent transaction and query execution.
Innovation Solution
A dynamic action queuing engine is employed to determine and manage lock chains by identifying needed and remaining queues through bitmap representations, allowing for efficient partition and queue management, and optimizing the ordering of transactions to minimize delays.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If lock chains are used to improve concurrency in partitioned databases, then transaction execution parallelism is improved, but unnecessary queue acquisitions on unused partitions cause delays
Solution Approach 1:
The patent segments the lock chain management by partition - each partition maintains its own independent queue and lock state. The bitmap representation divides the global lock state into individual partition bits, allowing selective acquisition and release of locks on only the partitions that are actually needed for each transaction, rather than acquiring locks on all partitions sequentially.
Solution Approach 2:
The patent applies partial action by acquiring locks on only the necessary partitions rather than all partitions. The bitmap tracking mechanism identifies exactly which partitions require lock acquisition for each transaction, avoiding the excessive action of acquiring locks on unused partitions that would cause unnecessary delays.
2Reliability
If a centralized lock manager is used to manage lock chains, then transaction coordination is improved, but the system becomes less scalable and more complex
Solution Approach 1:
The centralized lock manager is segmented into distributed partition-level lock managers. Each partition maintains its own queue and lock state independently, eliminating the need for a single centralized coordination point. This segmentation reduces the complexity and bottleneck associated with centralized lock management while maintaining transaction coordination through partition-level independence.
Solution Approach 2:
Each partition autonomously manages its own lock state and queue without requiring centralized coordination. The bitmap representation allows transactions to self-determine which partitions need locking based on their own access patterns, reducing the coordination overhead and complexity of the lock management system.
3Reliability
If all partitions are locked for each transaction, then data consistency is ensured, but unnecessary lock acquisitions reduce execution efficiency
Solution Approach 1:
The patent applies local quality by making lock acquisition selective rather than universal. Each partition's lock state is independently managed based on whether that specific partition is accessed by the transaction. The bitmap representation tracks which specific partition bits are set, allowing the system to apply locking only where needed (local quality) rather than globally across all partitions.
Solution Approach 2:
The system performs partial lock acquisition by locking only the necessary partitions rather than all partitions. This partial action maintains data consistency for accessed partitions while avoiding the excessive action of locking unused partitions, thereby preserving execution efficiency.
Data Source
AI summary
Various disclosed embodiments include methods and systems for managing lock or latch chains in concurrent execution of database queries. A method includes receiving a plurality of transactions, each transaction associated with one or more queuing requests. The method includes, for each transaction, determining one or more partition sets. Each partition set corresponds to one or more database partitions needed for the transaction. The one or more database partitions are included within a partitioned database. The method includes, for each transaction, determining one or more queues needed for the transaction and storing a bitmap representation of the one or more queues needed for the transaction. The one or more queues needed for the transaction correspond to the one or more database partitions needed for the transaction.