Process instances could influence each other, for example by signaling events, by changing globals or by putting / changing data in the session. In general, you can use one session for multiple process instances. Reason to create multiple sessions are for example scalability, or when you want to make sure process instances cannot inadvertedly influence each other.
we are now deciding whether how to use sessions. I see these general possibilitites:
- one session for all: which doesn't seem good solution based on Kris' answer, since we don't want processes influence each other by any chance
- new session created each time the session is needed
- one session for one process: for this solution I don't know where to save connectin between session and process instance. I imagine I have taskId or workItemId, from this I can get processInstanceId, but how I can get the information in which session it belongs?
What is your opinion on these possibilities?
1) don't take kris words in a bad way, there are some situations when you really need to have processes in the same session in order to handle interprocesses communications. It doesn't means that there are buggy behaviors when you run two or more processes in the same ksession.
2 and 3) Could be expensive if you think about persisting multiple session and based on the process you need to know which one load again. You will need to implement a mechanism to keep track which session -> which process
I personally think that you will start to understand more the posibilities that you have when you start looking at the persistence configurations and how they work.
Thank you for answer.
Just to make sure, what do you mean by persitence configuration exactly?
If you have wait states/safe points in your processes you will need a way to persist/store in a database the status of your business processes.
Take a look at the persistence section in the docs: http://docs.jboss.org/jbpm/v5.0/userguide/ch08.html