Hello,
I’m trying to reach a message start event, and I’ve noticed that it’s visible only if the transaction has been committed.
this fails with MismatchingMessageCorrelationException: Cannot correlate message ‘start-new-task’: No process definition or execution matches the parameters
while this works fine
why would the engine ability to understand that there is an event depend on whether the transaction has been committed or not to the DB?
Hi,
That is because the engine’s message correlation works by querying the table for event subscriptions, ACT_RU_EVENT_SUBSCR. And only a commit makes a new subscription visible for other actors.
Cheers,
Thorben
Hello @thorben , thanks for the super quick answer.
My naïve mental model thought that the bpmn was somehow “compiled” and so the fact that such start event existed was known even before running the bpmn, it’s right there in the bpmn definition, there was no need to think about the data or the transactions.
From what you say maybe it makes sense to always to commit (Async continuation “after”) after the main start event?
Why would anybody ever want a different behavior? (that is, failing this kind of correlations?)
Thanks
Hi,
Even then the subscription can only be created when the process instance starts, because it is unique per process instance (e.g. you can correlate via message name and process instance id).
That’s a valid idea but would break backwards compatibility affecting many users. And it’s at least questionable if this is really desired in every case. Note that with a BPMN parse listener you can programmatically extend the process engine to achieve that. Here’s a general parse listener example, you’d have to adapt it your use case.
Not necessarily failing correlations, but some people want to do some computations/validation to happen before the process instance really starts and becomes visible and correlatable. They could do that by having a first service task and only having a transaction boundary behind it. The current design gives more flexibility to the user. Some people also want to keep the amount of individual transactions minimal.
Cheers,
Thorben
Thank you very much for all this valuable information!
