how to use “per process instance” runtime strategy with Jbpm 6.4 in spring framework

1
votes

I have a business process with multi instance human task subprocess. Basically, it is leave approval process where one or many person may be involve to approve an employee leave leave approval business process

Here employee apply for leave for one or more people sign it to get task done.With Singleton strategy everything is running fine.Now I want to migrate it to "per process instance" runtime strategy. For that I modified code and added following code

this.kieSession = this.runtimeManager.getRuntimeEngine(ProcessInstanceIdContext.get()).getKieSession();

I have following doubts/questions:-

  1. Is creation of Kie Session is required only at the time starting of process ?

  2. How to extract process_instance_id for accessing kie session in future while signing the leave ?

  3. What is best approach to solve the above problem ?

  4. Is "per process instance" runtime strategy is enough or should I need to move to "per request" runtime strategy ?

  5. What is exact difference between "Singleton" and "per process instance" runtime strategy in terms of performance and resource usage ?

  6. Which one should I use if I have around 200 simultaneous user accessing my application ?

1
jbpmkie

1 Answers

2
votes

Here are the answers:

  1. KieSessions are created from the KieContainer so your client application can interact with the runtime. If you use the session only to start one process, that it is also fine. If you close the session the process will continue to run on the kie server(kie execution server)
  2. You can request all the instancess for one model(Process Definition) which is identified with GAV - group, artifact and version. In recent KIE versions - 7+ this is simplified as every deployment have unique identifier.
  3. Runtime strategy is not related to how you present the process and what functionality you expect from modeling it. I would say keep it to singleton by your description.
  4. Per process and per request strategies are only internal runtime properties of how the runtime is instantiated. This encapsulation should not change your functionality
  5. Singleton runtime is one executable and "per process instance" you have independent executions of every instance, so if some instance fail(run out of memory or other technical problem) the others can continue.
  6. Human user tasks access by simultaneous users is strange problem, as the task can be claimed only by one user at a time.

I hope I have shed some light on your understanding.

Cheers