I’m currently diving deeper into BPMN and Camunda. I experimented with one of the examples of Camunda Best Practice site, section Termination Events.
The description states that as soon as one of the tokens has finished, the other one is cancelled. However, I tried this very example within a deployed process engine as well as in a JUnit-Test. In both cases, only one path is executed and all others are completely ignored.
I’m perfectly aware that parallel token should be joined again. But I’m wondering: Is this the expected behaviour from the process engine implementation? According to the BPMN 2.0 specification a Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token…
Is the implementation choosen like that, in order to prevent unexpected situations? e.g. when the token is destroyed, but the Thread, which is currently executing the other Gateway, is still running?
What you’re seeing here is a demonstration of the fundamentals of how the engine works on a thread level.
So there are always going to be differences between how the engine works vs how the BPMN standard suggests things should progress. One of the key differences is that in order to maintain the integrity of the state and the variables of an instance the process engine will only ever move one toke at a time. It will progress as follows:
- Move token to next wait state.
- Look for other tokens to move
- If all tokens are waiting at wait states then commit the state to the database.
- If there are no tokens active or waiting in a process it ends
In the case above when the engine reaches the parallel gateway, it creates 2 token and the picks one to move first - but in this case there is a terminate event which means when the token arrives at it, the other token is destroyed meaning there are no more active tokens and the process ends.
thanks for your clarification - imakes perfect sense.
I guess I’ve been missleaded by the token simulator, which moves the token parallel
Well token simulation is a very good indication of how the standard expects things to be executed, so it is still a valuable insight
You can find more details in below Camunda docs
The Job Executor makes sure that jobs from a single process instance are never executed concurrently
Thanks for that, I’ll look into it.
I’ve read earlier in your forum, that it is indeed possible to achive real paralleism with adding ‘async before’ & ‘exclusive = false’ when splitting and ‘async before’ & ‘exclusive = true’ when joining the tokens?
That true @std but be careful with that, if you don’t completely understand the consequences of using these settings, you should avoid them
Allright, I’m going to avoid them
Although good to know.