Adaptive Stale Connection Recovery in Pools
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current connection pooling techniques either waste performance by passively detecting stale connections or unnecessarily investigate all connections, leading to inefficiencies in managing stale connections, especially when all connections in a pool become stale.
Innovation Solution
An adaptive threshold-based method where a connection is selected from a pool, and if the number of stale connections exceeds this threshold, recovery is performed on all connections; otherwise, recovery is limited to the stale connection, with the threshold adjusted based on the ratio of stale to good connections.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If passive technique is used to manage stale connections, then the client removes only detected stale connections, but performance decreases when all connections are stale
Solution Approach 1:
The system performs preliminary testing of connections in the pool proactively before they are needed for actual requests. By testing connections ahead of time and maintaining a separate tested connection pool, the system avoids the need to individually detect and handle stale connections at the moment of failure, thus preventing performance degradation when all connections might be stale.
Solution Approach 2:
The connection pool is segmented into two separate pools: an original pool and a tested pool. This segmentation allows the system to test and validate connections in advance, separating the testing function from the request handling function. When connections are needed, the system can quickly retrieve validated connections from the tested pool without performing individual staleness checks.
2Reliability
If active technique is used to handle stale connections, then the client investigates all connections proactively, but performance decreases with unnecessary work
Solution Approach 1:
Instead of testing all connections every time (excessive action), the system tests connections selectively based on the number of stale connections detected. When the number of stale connections is below a threshold, only necessary testing is performed. When the threshold is exceeded, comprehensive testing is triggered. This partial action approach avoids unnecessary work while maintaining reliability.
Solution Approach 2:
The system uses feedback from the number of stale connections detected to dynamically adjust its testing behavior. The stale connection count serves as feedback that triggers different levels of testing intensity, allowing the system to adapt its resource consumption based on actual connection pool health conditions.
3Productivity
If connection pooling is used to reuse connections, then performance improves by avoiding re-establishment, but connections become stale and unusable
Solution Approach 1:
The system performs preliminary validation of connections before they are reused for requests. By testing connections in advance and maintaining a separate tested pool of validated connections, the system ensures that reused connections are actually usable, preventing the reliability issue of stale connections while maintaining the performance benefit of connection pooling.
Solution Approach 2:
The system changes the state parameter of connections by separating them into different pools based on their validation status. Connections in the tested pool have a validated state, while those in the original pool await testing. This parameter change approach allows the system to track and manage connection usability without preventing connection reuse.
Data Source
AI summary
In an embodiment, in response to a request, a connection is selected from a pool of connections to a server. If the connection is stale and the number of stale connections encountered is greater than an adaptive threshold, then recovery is performed on all of the connections in the pool. If the number of stale connections is not greater than the adaptive threshold, then recovery is performed on the stale connection. A decision is made whether the connection is stale by sending the request to the server via the connection and detecting whether the sending encountered an error and by receiving a response from the server via the current connection and detecting whether the response indicates that the request encountered an error at the server.