Information Technology Reference
In-Depth Information
As you can see, there are four time lapses to which we should pay attention in the previ-
ous process definition section. The first one,
t1
, starts when we call the
startProcess
method on a KIE session object. Once it reaches the start of a User task, it will return con-
trol to the invoking thread, and wait for the User task to be finished. This could take a
really long time, and we don't want to have to depend entirely on memory until a user de-
cides to finish the task. This is one of the reasons persistence is needed for jBPM6.
Persistence is also needed for external system interactions, because of two main character-
istics:
• An external system interaction might take a lot of processing time. This could be
because it's using a slow, overused system. The problem is we might have many
different process invocations waiting for the next state in a single BPM system,
and if we leave all waiting states on external interactions in memory, we might
exceed the BPM system capacity.
• The external system could fail and need a retry at some other time. This is mostly
a consideration for asynchronous external interactions rather than for persistence.
However, while the process instance is waiting to do a retry at a given time, we
can release resources from the server if we store those process instances now and
reload them later on.
Now that we have understood that we might need to store and reload our process instances
at different time intervals, we have to deal with another particular problem: making sure
