Database Session State Recovery via Spooling and Replication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database servers face challenges in efficiently recovering from session failures, particularly in cloud environments where frequent database access failures occur, due to complex retry logic requirements and the need for additional modifications to handle connection failures between clients and database servers.
Innovation Solution
Implementing a method where session state is spooled to a repository on the first database server and replicated to additional servers, allowing for session recovery and command completion without re-retrieving data from the database, even if the initial session fails, by re-establishing the session on another server if the primary fails.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If retry logic is implemented in the application to handle session failures, then session recovery capability is improved, but application complexity increases
Solution Approach 1:
The patent extracts the retry logic and session recovery mechanisms from the application layer and relocates them to the database driver level. This allows the application to remain simple while the database driver handles session failures, connection re-establishment, and command re-execution automatically.
Solution Approach 2:
The database driver acts as an intermediary between the application and the database server. It intercepts commands, manages session state, and handles recovery operations, shielding the application from the complexity of session failure management while maintaining reliability.
2Reliability
If additional modifications are made to the application to handle frequent database access failures in cloud environments, then session failure handling capability is improved, but application complexity increases
Solution Approach 1:
The patent extracts all session failure handling logic from the application and consolidates it in the database driver. This includes connection management, session state tracking, and automatic retry mechanisms, allowing the application to remain unchanged and simple even in cloud environments with frequent failures.
Solution Approach 2:
The database driver provides self-service capabilities by automatically detecting session failures, re-establishing connections, and re-executing commands without requiring application-level intervention. This makes the system adaptable to cloud environments with frequent failures while keeping the application simple.
3Reliability
If data is re-retrieved from the database after session failure, then data consistency is ensured, but processing time increases
Solution Approach 1:
The patent implements preliminary action by spooling data to a session state repository before the session fails. When a session failure occurs, the data is already available in the repository, eliminating the need to re-retrieve it from the database and reducing processing time while maintaining consistency.
Solution Approach 2:
The patent creates a copy of the data in the session state repository before session failure. This copy can be used to restore the session state without requiring re-retrieval from the database, thus maintaining data consistency while minimizing time loss.
4Reliability
If session state is replicated to additional database servers, then session recovery capability is improved, but system complexity increases
Solution Approach 1:
The patent implements session state replication by creating copies of the session state and storing them in a repository on the database server. This allows the session state to be preserved and restored even if the original session is lost, improving recovery capability while using a straightforward copying mechanism rather than complex distributed systems.
Data Source
AI summary
Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.