Hello! I’m using Camunda 7, and, to avoid missing the message that will be sent back, I need to start waiting for it before requesting something to an external application.
I’ve seen in some other posts the recommendation to model it like in this image:
I’ve done some local tests and it seems to work because the job (from the delegate) and the subscription (from the message) are committed in a single transaction to the DB. However, before testing, I was afraid that we could have a behavior like:
one commit when the token reaches boundary A (top);
long waiting for some reason (e.g. the DB is too busy and slow);
another commit when the other token reaches boundary B (bottom).
Looking into the documentation, I didn’t understand why we have only one transaction for both paths. May someone help me understand if this will always be the case? Is the behavior that I described above possible? What if in the bottom path we had another delegate with “asyncBefore: true”, would we have two transactions instead of one?
You don’t have to set the “async before” flag at B; for a receive event, a transaction boundary is set implicitly and automatically. Setting it may even cause what you try to avoid since there will be two transactions necessary to establish an event subscription.
As to moving several tokens in one transaction: this is how Camunda works. It moves all possible tokens up to the next async point and then does one single commit. If something goes wrong, all the tokens are moved back to where they have been before the job started.
Yes! I didn’t intend to set “asyncBefore” at B, my intention in the picture was to “highlight” the relevant boundaries. But thanks anyway for the explanation!
this is what I was looking for confirmation! I couldn’t extract this info from the docs before.
However, thinking about what you said, I revisited the docs again today and it seems I found it:
Every time we use the Camunda 7 API to ask the workflow engine to do something (like e.g. starting a process, completing a task, signaling an execution), the engine will advance in the process until it reaches wait states on each active path of execution (…)
