Asynchronous Database Request Processing via Thread Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database systems face performance bottlenecks due to the synchronous processing of access requests that depend on persistent storage, leading to increased processing time and resource costs as the number of threads grows, especially when handling large volumes of data and transactions.
Innovation Solution
Implementing asynchronous processing for synchronous requests by maintaining a fixed thread pool size for request processing threads and using separate response processing threads to handle persistent storage operations, allowing request processing threads to return to the pool and process new requests while waiting for storage operations to complete.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If synchronous processing is used for access requests dependent on persistent storage, then request processing is straightforward and maintains simplicity, but processing time increases and throughput decreases due to blocking on storage operations
Solution Approach 1:
The patent segments the thread pool into two distinct groups: request processing threads that handle incoming access requests and initiate persistent storage operations, and response processing threads that wait for storage completion and return results to clients. This segmentation allows request processing threads to be immediately reused after initiating storage operations, eliminating the blocking behavior and improving throughput while reducing processing latency.
Solution Approach 2:
The patent implements preliminary action by having request processing threads initiate persistent storage operations and then immediately return to the thread pool without waiting for completion. The actual storage operations are performed in advance by the request processing thread, and the result is handled later by response processing threads. This preliminary action eliminates the waiting period that would otherwise block the thread, thereby improving productivity and reducing time loss.
2Productivity
If the number of threads is increased to handle more access requests concurrently, then throughput increases, but resource costs and system complexity increase
Solution Approach 1:
The patent implements dynamics by making the thread pool size configurable and adjustable based on system workload and resource availability. Rather than using a fixed large number of threads, the system can dynamically optimize the pool size to balance throughput requirements with resource constraints, reducing unnecessary thread management complexity while maintaining optimal productivity.
Solution Approach 2:
By segmenting threads into request processing and response processing roles, the patent reduces the total number of threads needed. Request processing threads are reused after initiating storage operations, while a smaller pool of response processing threads handles completion notifications. This segmentation decreases thread management complexity compared to using many threads that all wait for storage completion.
3Device complexity
If a fixed thread pool size is maintained, then resource utilization is optimized and overhead is reduced, but the system may lack flexibility in handling varying workload demands
Solution Approach 1:
The patent applies dynamics by allowing the fixed thread pool size to be configured and adjusted based on varying workload demands. The system can adapt to different scenarios by changing the pool size parameter, maintaining optimal resource utilization while providing flexibility to handle peak loads or resource constraints. This dynamic configurability resolves the contradiction between fixed management and workload adaptability.
Data Source
AI summary
A database system may implement asynchronous processing for synchronous requests received at the database. A pool of request processing threads may be maintained. As access requests for the database are received from clients, an available request processing thread in the pool may process the access request. The access request may be dependent on a persistent storage I/O operation, such that processing of the access request waits at least until the persistent storage I/O operation is complete. The request processing thread may perform processing operations for the access request so that persistent storage I/O operation is performed and become available to process other access requests. A response processing thread may determine that the persistent storage I/O operation for the access request is complete, and send a response to the client.