Distributed Locking Protocol for Partitioned Database Tables
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional locking protocols for partitioned and distributed database systems face challenges such as deadlock and increased network costs due to the use of a single lock manager, which leads to overhead and inefficiencies in multi-core parallel processing environments.
Innovation Solution
Implementing an optimistic intentional exclusive locking protocol where each node maintains its own local lock manager, allowing transactions to acquire IX locks on multiple nodes without deadlocks, and using statement routing to avoid conflicts between DML and DDL transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single centralized lock manager is used for the entire partitioned database table, then centralized control and coordination are achieved, but network costs increase and deadlock occurrences rise due to the single point of control
Solution Approach 1:
The patent segments the centralized lock manager into multiple distributed lock managers, with each database node maintaining its own lock manager. This segmentation eliminates the single point of control, reducing network communication overhead and preventing deadlocks by allowing concurrent lock operations across different nodes without centralized coordination bottlenecks.
Solution Approach 2:
Each database node performs lock management autonomously through its local lock manager, eliminating the need for centralized lock acquisition and release operations. Nodes independently manage their own locks and coordinate with peers only when necessary, reducing network traffic and improving system responsiveness.
2Ease of operation
If a single lock manager is used for the entire partitioned database table, then centralized control is maintained, but overhead from the master database node increases and performance scales poorly
Solution Approach 1:
The patent divides the monolithic lock management function into distributed components across multiple nodes. Each node's lock manager handles local lock operations independently, enabling parallel processing without centralized bottlenecks while maintaining operational simplicity through standardized local interfaces.
Solution Approach 2:
The patent combines the lock manager functionality directly into each database node, merging previously separate centralized lock management with distributed data storage. This integration eliminates communication overhead between separate lock manager and data nodes while maintaining centralized control principles at the local level.
3Device complexity
If conventional locking protocols are used in multi-core parallel processing environments, then simplicity of implementation is maintained, but performance is limited by centralized coordination overhead
Solution Approach 1:
The patent segments the locking protocol into node-specific instances that operate independently. Each node implements the full locking protocol locally, eliminating the need for centralized coordination and enabling true parallel processing across multiple cores while maintaining protocol simplicity through repetition rather than complexity.
Solution Approach 2:
The patent transitions from a single-dimension centralized locking model to a multi-dimensional distributed model where lock management occurs across multiple independent nodes simultaneously. This dimensional change enables parallel execution on multiple cores by distributing lock operations across the network dimension rather than serializing them through a single central point.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Systems, methods and computer program product embodiments for providing a locking protocol for partitioned and distributed database tables are disclosed herein. A locking method includes executing, by at least one processor, a first database transaction on a second node, attempting to acquire and acquiring a lock on the second node in intentional exclusive mode, executing, by the at least one processor, a second database transaction on a first node, acquiring a lock on the first node in exclusive mode and waiting to acquire a lock on the second node in exclusive mode, routing, by the at least one processor, the first database transaction to the first node and unsuccessfully trying to acquire a lock on the first node and committing, by the at least one processor, the first database transaction.