“Timers cannot fire before the transaction is committed to the database. Timers are explained in more detail later, but they are triggered by the only active part of the Process Engine where we use own Threads: The Job Executor. Hence they run in an own thread which receives the due timers from the database. But in the database the timers are not visible before the current transaction is visible. So the following timer will never fire”
I would like to know what’s the correct way to implement that logic? Thanks.
If you have a script task with a timer boundary event, mark the script task as asynchronous before. This will force a flush of process state to the database and thus the timer job will automatically be created. The script task will then run in a job executor (eg background) thread and the timer may fire.
Note: Timers on script or service tasks are unusual in my experience as script or service tasks normally should take seconds or less to execute. Timers on user tasks are common as user tasks can occur at the discretion of a user…
How about sub-process A attached with a timer? Do we need to turn on asy-before or asy-after?
The current issue I am facing now is that the sub-process A catches an event and after that, I use correlateMessage api to send the event and which has been successfully caught, but the running instance showed in camunda cockpit still says it’s inside the sub-process A and finally the time out is triggered.
Async before, async after, a user task, receive task and intermediate message events all create wait states, ie the process is waiting for an external stimulus. Hence these constructs force a flush to the database at which point timer jobs can be created. Hence to use timers effectively, you just need to ensure that you have a wait state at appropriate points…
As for your other question, if you post a simplified process model, I may be able to comment further…
