Let me first describe the way I am trying to use JBPM.
I have a UI running on an application server. JBPM is deployed on top of a Tomcat in a separate JVM. At the startup of the tomcat knowledge base is loaded, knowledge session is created and kept ready for the UI to call. The UI responds to user inputs and decides to launch a process in JBPM. The UI calls the JBPM through a web service and process instance gets started. The processes contain human tasks and may run for days( those lazy humans !!). The number of process instances could become high( may be thousands). All process instances info, task info everything is required to be persisted to database.
As the number of launched process instances go on increasing, the JBPM JVM shall run out of memory. The solution does not scale.
Approaches for problem resolution
There are two ways of handling this
a. Create only one session within the JBPM instance and let all process instance launches happen within this session. If JVM starts running out of memory, add more memory, more CPU firepower.
b. For each process start request, create a new sesson and load/unload the session as and when required. Live within whatever memory/CPU you have.
I am evaluating the two appraoches.
1. Does JBPM keep all process instance information in memory at all times ?
2. Does JBPM keep all the knowledge base in memory at all times ?
3. For approach b to work, the internal handling of JBPM should enable me to load/unload session at will. Does that work well? any firsthand experience ?
4. For approach b, if session dispose is called, do all process instances associated with that session go dormant ? In other words, if a session dispose is executed, are the process instances started by that session still in memory ?
5. My JVM crashes or needs to be restarted. Would all process instance information be loaded into memory automatically or would that be done programatically ?
If these have been answered anywhere else, please do point me to that location.