7.2. Runtime State
7.2.1. Runtime State
Whenever a process is started, an instance of that process is created. For instance, look at an example of a process representing a sales order. Each time a sales order is requested, one instance of the sales order process is created and contains only the information relevant to that sales order. When that instance is stored persistently, only the minimum set of information required to continue execution of the instance at some later time is stored. The engine automatically stores the runtime state in a database, ensuring that whenever the engine is invoked that any changes are stored at the end of the invocation and at safe points.
If it is ever necessary to restore the engine from a database, it is important not to reload the process instances and trigger them manually. Process instances will automatically resume execution if they are triggered, for example, by a timer expiring, the completion of a task that was requested by that process instance, or a signal being sent to the process instance. The engine will automatically reload process instances on demand. It is important to note that the snapshot of the process will be reloaded, and any changes that have occurred since the snapshot was taken will be lost.
The latest snapshot state can be retrieved using the following:
ksession.getProcessInstance(id)
The runtime persistence data should be considered internal, and the database tables where the data is stored should not be accessed directly. Where information about the current execution state of a process instance is required, refer to the history logs see Section 7.4.1, “History Log” .
7.2.2. Safe Points
The state of a process instance is stored at safe points during execution of the process. A safe point occurs when the process instance has completed, aborted, or reached a wait state in all parallel paths of execution. When the process instance is stored persistently at safe points, the current state of the process instance and all other process instances that might have been affected are stored.
7.2.3. Binary Persistence
Binary persistence, also known as marshaling, converts the state of the process instance into a binary dataset. Binary persistence is the mechanism used to store and retrieve information persistently. The same mechanism is also applied to the session state and any work item states.
When the process instance state is persisted, two things happen:
- The process instance information is transformed into binary data. For performance reasons, a custom serialization mechanism is used and not normal Java serialization.
- The binary data is stored alongside other metadata about the process instance. This metadata includes the process instance ID, process ID, and the process start date.
Apart from the process instance state, the session itself can also store other forms of state, such as the state of timer jobs. The session can also store the data that any business rules would be evaluated over. This session state is stored separately as a binary dataset along with the ID of the session and some metadata. The session state can be restored by reloading the session with the given ID. The session ID can be retrieved using
ksession.getId().
Note that the process instance binary datasets are usually relatively small, as they only contain the minimal execution state of the process instance. For a simple process instance, the binary datasets usually contain one or a few node instances, i.e., any node that is currently executing and any existing variable values.
As a result of binary persistence, the data model is both simple and small:
Figure 7.1. Data Model
The
sessioninfo entity contains the state of the (knowledge) session in which the process instance is running.
Table 7.1. SessionInfo
| Field | Description | Nullable |
|---|---|---|
id | The primary key | NOT NULL |
lastmodificationdate | The last time that the entity was saved to the database | |
rulesbytearray | The binary dataset containing the state of the session | NOT NULL |
startdate | The start time of the session | |
optlock | The version field that serves as its optimistic lock value |
The
processinstanceinfo entity contains the state of the process instance.
Table 7.2. ProcessInstanceInfo
| Field | Description | Nullable |
|---|---|---|
instanceid | The primary key | NOT NULL |
lastmodificationdate | The last time that the entity was saved to the database | |
lastreaddate | The last time that the entity was retrieved (read) from the database | |
processid | The name (ID) of the process | |
processinstancebytearray | This is the binary dataset containing the state of the process instance | NOT NULL |
startdate | The start time of the process | |
state | An integer representing the state of the process instance | NOT NULL |
optlock | The version field that serves as its optimistic lock value |
The
eventtypes entity contains information about events that a process instance will undergo or has undergone.
Table 7.3. EventTypes
| Field | Description | Nullable |
|---|---|---|
instanceid | This references the processinstanceinfo primary key and there is a foreign key constraint on this column | NOT NULL |
element | A text field related to an event that the process has undergone |
The
workiteminfo entity contains the state of a work item.
Table 7.4. WorkItemInfo
| Field | Description | Nullable |
|---|---|---|
workitemid | The primary key | NOT NULL |
name | The name of the work item | |
processinstanceid | The (primary key) ID of the process: there is no foreign key constraint on this field | NOT NULL |
state | An integer representing the state of the work item | NOT NULL |
optlock | The version field that serves as its optimistic lock value | |
workitembytearay | This is the binary dataset containing the state of the work item | NOT NULL |
