jBPM uses hibernate's second level cache for keeping the process definitions in memory after loading them once. The process definition classes and collections are configured in the jBPM hibernate mapping files with the cache element like this:

<cache usage="nonstrict-read-write"/>

Since process definitions (should) never change, it is ok to keep them in the second level cache. See also the section called “Changing deployed process definitions”.

The second level cache is an important aspect of the JBoss jBPM implementation. If it weren't for this cache, JBoss jBPM could have a serious drawback in comparison to the other techniques to implement a BPM engine.

The default caching strategy is set to nonstrict-read-write. During runtime execution of processes, the process definitions are static. This way, we get the maximum caching during runtime execution of processes. In theory, caching strategy read-only would be even better for runtime execution. But in that case, deploying new process definitions would not be possible as that operation is not read-only.