JBoss Community

Re: jPBM 5.1, persistent processes get finished without regard to session

created by Miljenko Norsic in jBPM - View the full discussion

Hi Maciej,

 

thanks for the reply! I've checked your statement about environment, and when I set up two different environments, it works OK.

Unfortunately, it is not that obvious what is the right way to do it, especially taking into consideration that persistent examples are scattered around and not included into JUnit tests (if I'll get some time, I'll try to add it into JUnit tests because I think jBPM deserves much more examples to be more widely accepted in community, because lot of us are struggling with rather incomplete set of samples to build our processes).

 

As for the signalling processes, I didn't realized that processes live separately from their knowledge sessions, because:

1. process cannot live without its knowledge session (we create a process on a knowledge session, right?)

2. session handle and process handle are persisted together. It means that when I reach some safe state point in process, upon its wakeup I'm going to receive a deserialized knowledge session instance and its child process instances

3. I can create many process instances on a same session instance

4. rules are also first-class citizens in knowledge session, similar to processes, and processes cannot execute without rules (if they use rule tasks).

 

As I see it, process has its parameters only, and the rest is taken from the session. Please correct me if I'm wrong.

Therefore it is somehow strange to call signalEvent(eventId, param) on a ksession and as a result all process instances are notified, and not only those that belong to that particular knowledge session.

 

Also, one thing I've spotted and is by my humble opinion not correct, is that when I call

 

processInstance.signalEvent(type, eventData);

 

only that particular process instance is signaled. For example, if this process instance contains a sub-process with that event, signal is not propagated to a child process.

So, in general, I think more scoping would allow process creators more freedom in process creation, and avoid ugly workarounds if one wants to build something uncommon.

 

Thanks,

Miljenko

Reply to this message by going to Community

Start a new discussion in jBPM at Community