Runtime Database Failover via Intermediary Memory Store
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software applications face inefficiencies and user dissatisfaction when database systems crash, as they often present error messages or pause, and customizing applications to handle database unavailability is challenging for developers and inefficient for users.
Innovation Solution
A runtime database error handling mechanism that creates an alternate data store to continue operations transparently to users and developers, merging data back into the primary database once it becomes available, allowing applications to function seamlessly without interruption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the software application waits for the database system to become available or presents error messages, then data consistency is maintained, but user satisfaction and application efficiency deteriorate
Solution Approach 1:
The patent introduces an intermediary component (file system/alternate data store) between the software application and the database system. When the database is unavailable, the application continues to operate by storing data in this intermediary layer, which later synchronizes with the database when it becomes available again, thus maintaining both user satisfaction and data consistency.
Solution Approach 2:
The patent implements preliminary action by pre-configuring an alternate data store and synchronization mechanism before database unavailability occurs. The application is designed to automatically switch to using the file system as a backup data store when the database becomes unavailable, and to resume normal database operations when it becomes available again, without requiring user intervention or causing service interruption.
2Productivity
If the application is customized to handle database unavailability, then application functionality during downtime is improved, but development complexity and difficulty increase
Solution Approach 1:
The patent creates a universal failover framework that can be applied to multiple different software applications without requiring custom implementation for each. The framework provides a standardized interface and automatic failover mechanism that works across different applications, reducing development complexity while maintaining application functionality during database downtime.
Solution Approach 2:
The patent implements self-service by designing the failover mechanism to automatically detect database unavailability, switch to the alternate data store, and synchronize back when the database becomes available again. This automatic operation eliminates the need for complex manual customization and ongoing maintenance of failover logic in each application.
3Reliability
If the application pauses until the database system becomes available, then data integrity is preserved, but operational efficiency and response time deteriorate
Solution Approach 1:
The patent uses the file system as an intermediary data store that allows the application to continue operating with local data when the database is unavailable. This intermediary layer preserves data integrity through structured storage and enables continued productivity by allowing read/write operations locally without waiting for database availability.
Solution Approach 2:
The patent ensures continuity of useful action by enabling the application to perform CRUD operations continuously on the alternate data store when the database is unavailable. The synchronization process resumes data replication to the database when it becomes available again, maintaining both data integrity and continuous operational efficiency without pauses or interruptions.
Data Source
AI summary
Systems and methods include receiving an exception raised by a database storage system in response to a database operation requested by an application, providing, in response to the exception, the application with a pointer to a failover framework comprising a memory store, receiving, from the application and at the failover framework, a request to write first data, storing, in response to the request to write first data, the first data in a tree structure of the memory store in chronological order, receiving, from the application and at the failover framework, a request to read second data, and, in response to the request to read second data, sorting the tree structure primarily by user and secondarily by chronological order and reading the second data from the sorted tree structure.