Chapter 13. Persistence
The runtime data of the Process Engine can be persisted in data stores. The persistence mechanism saves the data using marshalling: the runtime data is converted into a binary dataset and the dataset is saved in the data storage.
Note that persistence is not configured by default and the engine runs without persistence.
Note
The runtime data is saved using marshalling (binary persistence). The marshalling mechanism is a custom serialization mechanism.
Red Hat JBoss BPM Suite will persist the following when persistence is configured:
- Session state: this includes the session ID, date of last modification, the session data that business rules would need for evaluation, state of timer jobs.
- Process instance state: this includes the process instance ID, process ID, date of last modification, date of last read access, process instance start date, runtime data (the execution status including the node being executed, variable values, etc.)and the eventtypes.
- Work item runtime state: this includes the work item ID, creation date, name, process instance ID, and the work item state itself.
Based on the persisted data, it is possible to restore the state of execution of all running process instances in case of failure or to temporarily remove running instances from memory and restore them later. By default, no persistence is configured.
To allow persistence, you need to add the jbpm-persistence jar files to the classpath of your application and configure the engine to use persistence. The engine automatically stores the runtime state in the storage when the engine reaches a safe point. Safe points are points where the process instance has paused. When a process instance invocation reaches a safe point in the engine, the engine stores any changes to the process instance as a snapshot of the process runtime data. However, when a process instance is completed, the persisted snapshot of process instance runtime data is automatically deleted.
If a failure occurs and you need to restore the engine runtime from the storage, the process instances are automatically restored and their execution resumes so there is no need to reload and trigger the process instances manually.
The runtime persistence data is to be considered internal to the engine. You should not access persisted runtime data or modify them directly as this might have unexpected side effects.
To obtain information about the current execution state, refer to the history log. Query the database for runtime data only if absolutely necessary.
13.1. Session Copy linkLink copied to clipboard!
Copy linkLink copied to clipboard!
Sessions are persisted as
SessionInfo
entities. These persist the state of the runtime KIE session, and store the following data:
Field | Description | Nullable |
---|---|---|
id
|
primary key
|
false
|
lastmodificationdate
|
last saved to data store
|
N/A
|
rulesbytearray
|
binary dataset with session state (binary blob
|
false
|
startdate
|
session start
| |
optlock
|
version number used to lock value for optimistic locking
| |