Batching Lock Requests to Reduce Network Bandwidth in Shared Disk Databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In shared disk database systems, the number of lock communications significantly impacts performance and resource consumption due to the high number of messages required for lock acquisition, which can hinder system throughput.
Innovation Solution
The solution involves pre-fetching locks by determining the required and future locks for operations like row updates, deletes, and inserts, and sending a single message to the lock manager, as well as performing row modification operations in two executions to combine lock requests and reduce network traffic.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If multiple separate lock requests are sent to the lock manager for each lock needed in a database operation, then each lock can be acquired reliably, but the number of network messages increases significantly, consuming more bandwidth and processing resources
Solution Approach 1:
The patent combines multiple separate lock requests into a single batched lock request message. Instead of sending individual messages for each lock needed by a database operation, the system aggregates all required lock identifiers into one message and sends it to the lock manager in a single network transaction, thereby reducing network bandwidth consumption while maintaining reliable lock acquisition.
Solution Approach 2:
The patent performs preliminary identification of all locks required for a database operation before sending the lock request. By determining in advance which locks will be needed (including future locks required during the operation), the system can batch all necessary lock requests together in one message, avoiding multiple separate communications and reducing overall network traffic.
2Reliability
If multiple separate lock requests are sent to the lock manager, then each lock can be acquired with proper authorization, but the processing overhead and message handling complexity increase
Solution Approach 1:
The patent merges multiple lock requests into a single batched message that contains multiple lock identifiers. The lock manager processes this single message to authorize and grant multiple locks atomically, reducing the complexity of message handling while maintaining proper authorization control through centralized validation of all requested locks in one processing cycle.
Solution Approach 2:
The batched lock request mechanism serves multiple functions simultaneously: it reduces network traffic, simplifies message processing by consolidating multiple requests into one transaction, and maintains comprehensive authorization control. This multi-functional approach resolves the contradiction by making the lock acquisition system more efficient without sacrificing reliability.
3Reliability
If locks are acquired for all currently needed resources, then data consistency is maintained, but the number of locks held increases, potentially blocking other operations and reducing system throughput
Solution Approach 1:
The patent applies preliminary action by identifying and acquiring future locks in advance, before they are actually needed during the database operation. This allows the system to maintain data consistency by having all necessary locks available when needed, while also improving throughput by preventing intermediate lock acquisition delays and reducing the time that locks are held in a waiting state.
Solution Approach 2:
The patent implements skipping by pre-acquiring all necessary locks in a single batched operation, thereby skipping the intermediate steps of multiple separate lock acquisition messages and their associated processing delays. This rushes through the lock acquisition phase efficiently, maintaining data consistency while minimizing the time locks are held, thereby improving overall system throughput.
Data Source
AI summary
Lock communications in a shared disk database system is reduced by several approaches: sending a single message to a lock manager for locks required for an operation and locks that will be required in the future, the operations may include row update, row delete, large scan, and row insert; performing an operation in two executions, where in a first execution locks required for the operation is determined without performing the operation, and in a second execution a single message is sent to a lock manager for the required locks and the operation is performed; in free space searching, sending a single message to a lock manager for row and page locks before a row insert is actually performed; and granting locks in an unfair manner.