Decoupling Static Program Data from Execution State
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing continuation-based runtime systems face significant processing burdens and storage footprints when pausing and resuming programs across different processes, and require exact static program data to resume execution states.
Innovation Solution
Separating static program data from execution state data, allowing for the storage and rehydration of execution state information separately from static program data, and using a tree walking algorithm to manage unique identifiers for activities, enabling efficient pausing, resuming, and modifying of programs without requiring the same static data.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If complete program data is stored during pausing, then execution state can be fully preserved, but storage footprint increases significantly
Solution Approach 1:
The patent segments program data into static program data (activity definitions, configurations) and execution state data (activity instances, current positions). Only execution state data is persisted during pausing, while static program data remains in memory or is reloaded from original sources. This segmentation reduces storage footprint by excluding redundant static data from persistence operations.
Solution Approach 2:
The patent extracts and separates execution state information from complete program data. The execution state is represented as minimal data structures containing only necessary runtime information (activity instance identifiers, current activity positions, continuation points). This extraction eliminates the need to store full program definitions, achieving compact persistence.
2Reliability
If complete program data is loaded during pausing, then execution state can be fully captured, but processing burden increases significantly
Solution Approach 1:
The patent divides the data handling process into two segments: (1) capturing only execution state data during pausing operations, and (2) maintaining static program data separately in memory or external storage. This segmentation reduces the amount of data processing required during pause/resume operations, lowering the processing burden while preserving execution state integrity.
Solution Approach 2:
The patent performs preliminary actions by maintaining static program data in memory or pre-loaded state before pausing occurs. When pausing is needed, the system only needs to capture the current execution state (a minimal data set) rather than processing complete program data. This preliminary preparation significantly reduces the processing burden during actual pause operations.
3Productivity
If program modifications are made directly on running instances, then changes can be applied immediately, but system complexity and risk increase
Solution Approach 1:
The patent implements dynamic program modification by allowing static program data to be updated independently of running activity instances. The system dynamically reloads or rehydrates activity instances with updated static program data without requiring direct modification of running code. This dynamic approach enables immediate program changes while maintaining system stability through separate data layers.
Solution Approach 2:
The patent uses copying mechanisms where updated static program data is copied or rehydrated into activity instances during resume operations. Rather than modifying running instances directly, the system creates updated copies of activity definitions and associates them with existing execution state. This copying approach simplifies modification operations and reduces system complexity by avoiding direct manipulation of running code.
Data Source
AI summary
Persisting execution state of a continuation based runtime program. The continuation based runtime program includes static program data defining activities executed by the program. One or more of the activities are parent activities including sequences of child activities. The continuation based runtime program is loaded. A child activity to be executed is identified based on scheduling defined in a parent of the child activity in the continuation based runtime program. The child activity is sent to a continuation based runtime separate from one or more other activities in the continuation based runtime program. The child activity is executed at the continuation based runtime, creating an activity instance. Continuation state information is stored separate from the static program data by storing information about the activity instance separate from one or more other activities defined in the continuation based runtime program.