1 of 1 people found this helpful
that depends on the runtime strategy your deployment unit is deployed with. If you use default one (singleton) then they will be run sequentially as ksession access is synchronized. Change strategy to per request or per process instance and they should be executed concurrently.
Thanks for your answer Maciej.
I read about different runtime startegies.
Singleton - single knowledge session that will execute all process instances;
Per Request - every request (which is in fact call to getRuntimeEngine) will get new knowledge session;
Per Process Instance - every process instance will have its dedicated knowledge session for the entire life time.
Wich one would you suggest for processes containing long running tasks?
How can I change a deployment runtime strategy of an existing deployment or deploy using a non singleton runtime strategy?
1) I was able to create a new deployment unit with per process runtime strategy in the Deployments page, but if I press the [Build & Deploy] button in "Project Editor" page runtime strategy changes to Singleton. Shoud I delete deployments and create them again every time I edit a process?
2) In my process long running tasks are handled by Asynchronous handlers. Which runtime startegy would you reccomend?
yes, if you use deployments view then after build and deploy you need to remove it and the redeploy manually to change the strategy. In 6.1 you can use deployment descriptor (See docs) to enforce given strategy for kjar.
Hi Maciej ,
I have one Process for which many process instances are running on Singleton runtime strategy now for that same process I want to change runtime strategy to PER_REQUEST OR PER_INSTANCE so is it possible to change runtime strategy without redeploy or killing previous instances ?