Software Parameter Caching for Downtime-Free Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software applications face challenges in balancing flexibility for parameter alterations without system downtime and maximizing speed in multi-user environments, where parameters are either hard-coded or stored locally, leading to conflicting requirements of flexibility and performance.
Innovation Solution
Implementing a caching system where parameters are checked in cache memory first, with updates from a database or flat file, allowing frequent parameters to be updated without downtime by prioritizing database sources over flat files, and dynamically moving parameters between storage types based on usage frequency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If parameters are hard coded into the software or stored locally in memory, then execution speed is maximized and response time is minimized, but the software loses flexibility and requires system downtime to update parameters
Solution Approach 1:
The patent segments parameters into different categories based on their update frequency and criticality. Frequently accessed parameters are cached in memory for fast access, while less frequently updated parameters remain in the database. This segmentation allows the system to maintain high execution speed for common operations while preserving flexibility through database updates without requiring full system downtime.
Solution Approach 2:
The system performs preliminary actions by pre-loading parameters into cache memory before they are needed during software execution. This allows the software to access parameters rapidly from cache during normal operation, while parameter updates can be performed in the database beforehand or during maintenance windows without impacting real-time performance.
2Adaptability or versatility
If parameters are stored in a flat file on the application server, then parameter updates are possible without hard coding, but the software application still needs to be taken out of service to update parameters
Solution Approach 1:
Parameter updates are performed in the database beforehand or during maintenance windows before the software needs to access them. The caching mechanism ensures that updated parameters are loaded into memory in advance, allowing the software to continue operating with cached values while database updates occur without requiring system shutdown.
Solution Approach 2:
The system maintains copies of parameters in multiple locations: the authoritative copy in the database and working copies in cache memory. This copying approach allows updates to be made to the database copy without affecting the running software, which continues to use its cached copy until a refresh occurs.
3Adaptability or versatility
If parameters are frequently updated in the database, then flexibility and adaptability are improved, but system performance may degrade due to increased data access overhead
Solution Approach 1:
The patent segments parameters into frequently accessed and infrequently updated categories. Frequently accessed parameters are cached in memory for rapid access during software execution, while infrequently updated parameters remain in the database. This segmentation minimizes database access overhead during normal operation while maintaining the ability to update parameters as needed.
Solution Approach 2:
Different storage locations are assigned different quality characteristics based on local requirements. Cache memory provides high-speed local access for performance-critical parameters, while the database provides persistent storage for all parameters. This local quality differentiation optimizes both speed and flexibility without compromising overall system performance.
Data Source
AI summary
A method and apparatus is disclosed for allowing the updating and overriding of software parameters used by one or more software programs. The parameters are preferably in cache. When the system needs any such parameter, it first checks cache, then a preferably remotely located database, and then, preferably a flat file on the same computer as the cache. The checking is done in the foregoing order, and the parameter is used upon locating a current version of it. If the current version is obtained from anywhere other than the cache, it is put into cache.