Information Technology Reference
In-Depth Information
Why do we need persistence and
transactions?
So far, we've dealt with very short-lived processes. Running inside a JUnit test, process in-
stances last very few milliseconds, and having them in memory is sufficient for those envir-
onments. However, in real-life situations, we don't usually create interactions between sys-
tems and humans without having long wait states in between. This is especially relevant for
the case of processes with human tasks, where users backed up with too much work might
have a pending task assigned to them for hours, days, or even more. For each of the pro-
cesses in your environment, you should be able to determine whether it should be a persist-
ent or a nonpersistent process depending on how long-lived each of its process instances
will be. From this perspective, you will find these two top-level categories:
• In-memory processes
• Long running processes (also known as persistent processes)
In-memory processes are usually short-lived processes that perform entirely automatic syn-
chronous interactions. Depending on the complexity of each automatic interaction, some
processes might take longer to complete than others, but with this type of process, in gener-
al, a range that might go from a few seconds to a few minutes is more likely.
Long-running processes, on the other hand, might take several minutes to complete the
fastest process instance—with more
real
values ranging from hours to even years, depend-
ing on the nature of the process. Keeping an in-memory reference for such processes be-
comes impractical and even impossible to guarantee in some cases. For such processes, we
need a persistence mechanism to keep a recoverable reference to the process whenever it is
needed.
Several questions will help you determine whether your process will need to be persisted or
not:
• Does your process interact with other components? How slow are they? How
prone to failure are they? If external interactions are really slow and asynchronous
by nature, or prone to errors and retries, then a persistent process will be able to
handle it better than an in-memory process.
• Should the process be able to recover from a failure state? If we should manually
recover from an error state, we will need to keep a reference of the process to re-
cover it later on.
