Software Upgrade Correction via Segmented Repository Lock
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
During software upgrade procedures, existing systems face challenges in allowing corrections and changes while maintaining data persistency, leading to downtime and potential data loss or corruption, as changes made during upgrades are not migrated to the new system.
Innovation Solution
Implementing a soft repository lock that selectively permits transport requests for corrections on white-listed object types, enabling changes to be made during upgrades without disrupting the system, by using a shadow repository and cloning tables to ensure consistent deployment.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the system is locked during upgrade procedure to maintain data persistency, then data loss and corruption are prevented, but system availability and productivity deteriorate due to downtime and blocked corrections
Solution Approach 1:
The patent segments the repository into two distinct parts: a locked repository that maintains data persistency during upgrade, and an unlocked correction repository that allows corrections to be made. This segmentation enables simultaneous data protection and correction capability, resolving the contradiction between reliability and productivity.
Solution Approach 2:
The patent introduces an intermediary mechanism (correction repository with soft lock) that mediates between the locked repository and the upgrade process. This intermediary allows corrections to be staged and applied without compromising the integrity of the main repository, enabling both data protection and system availability.
2Reliability
If the system is locked during upgrade procedure, then data corruption is prevented, but correction and customization operations are blocked
Solution Approach 1:
The repository is segmented into a locked portion for data integrity and an unlocked correction portion for operational flexibility. This allows corrections to be made without compromising data integrity, as corrections are applied to the segmented correction repository rather than the locked main repository.
Solution Approach 2:
Corrections are prepared and staged in the correction repository before being applied to the main system. This preliminary action in a controlled environment ensures data integrity is maintained while still enabling correction operations to be performed.
3Productivity
If changes are made during upgrade procedure, then system responsiveness to errors is improved, but data persistency and consistency deteriorate due to non-migrated changes
Solution Approach 1:
Corrections are prepared and validated in advance in the correction repository before being applied to the main system. This preliminary action ensures that changes are ready and consistent before deployment, maintaining data consistency while enabling rapid error response.
Solution Approach 2:
The correction repository acts as an intermediary staging area where changes are prepared and validated before being migrated to the main system. This intermediary process ensures data consistency is maintained while enabling corrections to be made in response to errors.
4Reliability
If a hard lock is applied during upgrade, then data safety is ensured, but downtime increases and system access is completely blocked
Solution Approach 1:
The system is segmented into locked and unlocked portions, allowing the main repository to remain locked for data safety while the correction repository remains accessible. This segmentation eliminates complete downtime by enabling parallel operations in the unlocked segment.
Solution Approach 2:
The lock mechanism is made dynamic rather than static. Instead of a hard lock that completely blocks access, the system implements a soft lock that selectively restricts access to specific portions of the repository while allowing corrections in other portions. This dynamic approach reduces downtime while maintaining data safety.
Data Source
AI summary
Methods, systems, and computer-readable storage media for applying corrections during an upgrade procedure of a software management system include actions of receiving a set of white-listed object types, receiving a set of corrections to be imported, the set of corrections including a set of objects, to which corrections are to be applied during the upgrade procedure, determining a set of object types included in the set of corrections, the set of object types including one or more object types, and selectively permitting one or more transport requests to effect corrections of the set of corrections to be issued during the upgrade procedure based on the set of object types and the set of white-listed object types.