1 of 1 people found this helpful
you can't change strategy for already running process instances as they won't have context established thus the error message you see. Per process instance means that on process creation ksession will be saved and managed with the process instance. Since you use singleton there is no such info.
Thank you for the reply. Is there any way we can identify whether the request is raised using Singleton or Per Process Strategy? If that is case, then we can at least handle the request accordingly.
not sure what you try to achieve but that would mean you should have two runtime manager instances in place and then use their identifiers to distinguish. For example when you initially used singleton and then switched to per process instance that would mean you should still have both available until all process instances from singleton are completed. At the same time you should avoid creating new instances from the singleton one and always direct them to the per process instance.
I just want to now how we can identify the process that are raised using singleton session strategy so that i can handle it accordingly. It seems that the approach you suggested will work without any problem. Thank you for the solution.
I'm experiencing same kind of scenario.
I have two runtime strategies deployed, singleton (old processes: version 1) and per process instance (new processes: version 2). I'm trying to migrate processes from version 1 (singleton) to version 2 (per process instance). While migrating, it updates the process version to 2 but it shows the following error while browsing the task,
error: "Unexpected error occurred: org.kie.internal.runtime.manager.SessionNotFoundException:No session found for context 69970"
How can I handle this scenario?
quick question: do process migration in bpm6 works across runtime strategies? or under same strategy only?