Chapter 12. 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.

12.1. Session

Sessions are persisted as SessionInfo entities. These persist the state of the runtime KIE session, and store the following data:
Expand
Table 12.1. 
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
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat