Replay Driver for Database Session State Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing client-server systems face challenges in maintaining session state integrity during database session failures, leading to incomplete transactions, data loss, and user frustration due to the inability to determine the outcome of in-progress operations, resulting in duplicate submissions and logical corruption.
Innovation Solution
The implementation of techniques to recover and replay database session states, including the use of replay drivers and Continuity Management protocols, which allow clients to maintain information for possible replay of commands across sessions, ensuring that non-transactional state is preserved and transactions are only re-executed if they did not commit, thereby avoiding data corruption and user re-entry.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the server sends information to maintain for possible replay of commands, then session state recovery capability is improved, but client memory usage and processing overhead increase
Solution Approach 1:
The server performs preliminary actions by sending replay information to the client before a failure occurs. This allows the client to have the necessary information ready for potential replay, improving recovery capability while managing resource usage through selective maintenance of replay data.
2Manufacturing precision
If the client replays all commands to recover session state, then session state integrity is improved, but transaction execution time increases due to potential duplicate transactions
Solution Approach 1:
The system uses feedback mechanisms where the server tracks which transactions have been committed and provides this information to the client. The client uses this feedback to determine which transactions need replay, avoiding duplicate execution of already-committed transactions while maintaining session state integrity.
Solution Approach 2:
The server performs preliminary tracking of transaction commit status and communicates this information to the client before replay is needed. This allows the client to efficiently determine which transactions require replay without having to replay all transactions, reducing execution time while maintaining integrity.
3Ease of operation
If the system masks database session unavailability from users, then user experience is improved, but system complexity increases due to replay management
Solution Approach 1:
The replay driver acts as an intermediary between the client and server, managing the complexity of replay operations. It intercepts commands, maintains replay information, and handles the replay process automatically, shielding users from the underlying complexity while improving user experience during failures.
4Measurement precision
If separate queues are used for transactional and non-transactional statements, then replay accuracy is improved, but device complexity increases
Solution Approach 1:
The system segments replay information into separate queues for transactional and non-transactional statements. This segmentation improves replay accuracy by allowing precise control over which types of statements are replayed, while the complexity of queue management is handled automatically by the replay driver infrastructure.
Data Source
AI summary
Transactional and non-transactional data for maintaining session state is described. In a session, a server instance receives, from a client, a request to execute transactional commands and non-transactional commands. The server instance sends at least one first directive executable at the client to store, in a first set of information, one or more first items representing one or more particular transactional commands that are open but not yet committed. The first set of information is maintained separately from a second set of information including one or more second items representing one or more particular non-transactional commands that have been processed. Based on committing one or more particular transactional commands, the server instance sends at least one second directive executable at the client to purge, from the first set of information, the one or more first items without purging, from the second set of information, the one or more second items.