Show Table of Contents
Chapter 13. Persistence and Transactions
13.1. Process Instance State
JBoss BPM Suite allows the persistent storage of certain information.An example of the information stored is the process runtime state. Storing the process runtime state is necessary in order to be able to continue execution of a process instance at any point if something goes wrong. The process definitions and the history information (logs of current and previous process states already) can also be persisted.
13.1.1. Runtime State
Whenever a process is started, a process instance is created, which represents the execution of the process in that specific context. For example, when executing a process that specifies how to process a sales order, one process instance is created for each sales request. The process instance represents the current execution state in that specific context, and contains all the information related to that process instance. Note that it only contains the (minimal) runtime state that is needed to continue the execution of that process instance at some later time. However, it does not include information about the history of that process instance if that information is no longer needed in the process instance.
The runtime state of an executing process can be made persistent, for example, in a database. This allows to restore the state of execution of all running processes in case of unexpected failure, or to temporarily remove running instances from memory and restore them at some later time. JBoss BPM Suite allows you to plug in different persistence strategies. By default, if you do not configure the process engine otherwise, process instances are not made persistent.
If you configure the engine to use persistence, it automatically stores the runtime state into the database. You do not have to trigger persistence yourself, the engine takes care of this when persistence is enabled. Whenever you invoke the engine, it ensures that the changes are stored at the end of that invocation. Whenever something goes wrong and you restore the engine from the database, you must not reload the process instances and trigger them manually to resume execution, as process instances automatically resume execution if they are triggered.
You must not try to access database tables containing runtime persistence data directly and try to modify these, as changing the runtime state of process instances without the engine's knowledge may have unexpected results. In most cases where information about the current execution state of process instances is required, the use of a history log is mostly recommended. In some cases, it may still be useful to for example query the internal database tables directly, but you must only do this if you know what you are doing.
13.1.1.1. 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 13.1. Data Model
The
sessioninfo entity contains the state of the (knowledge) session in which the process instance is running.
Table 13.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 13.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 13.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 13.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 |
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.