We have one timer inside that timer we are calling another timer. The first-timer times out. What will happen to the second timer?
The second timer continues running, because that's a separate schedule being triggered.
If you would like to have the second timer to stop processing, you need to have a site property or an entity containing an attribute that will be set to a specific value by the first timer when a timeout happens, and check in the second timer on the change to that specific value and stop/cancel processing in the second timer.
Hello Shubham,
If the timer reaches its timeout, then the entire transaction is aborted and data is rolled back.
You have several ways to control this behavior:
Kind regards,
Rui Barradas
Jeroen is right, timers are asynchronous processes. And each timer is a different web request for the front-end server.
Actually the second timer starts running in parallel with the first timer, both will be running at the same time (considering that the platform has available slots - by default one front-end server can run 3 timers at the same time).
If the first timer times out, the second one will keep running. They are independent.
Just to add to the above, you aren't "calling" another timer, you are "waking" it, i.e. you add a request to start the timer to the scheduler queue. There is absolutely no difference between starting a timer this way or doing it manually via Service Center. For more background on timers, see my article here.
Hi Guys,
Thanks for this information. I have one more question related to this, what will happen to first-timers data if the timer time-out and we are not using commit transactions?
In OutSystems, when one timer calls another timer and the first timer times out, the behavior of the second timer depends on how it's implemented and whether it relies on the first timer's execution for any specific functionality.
Independent Execution: If the second timer is designed to execute independently of the first timer and doesn't rely on any data or actions performed by the first timer, it will continue its execution as usual. The timeout of the first timer won't affect the execution of the second timer.
Dependent Execution: If the second timer depends on the first timer's execution or any data/state set by the first timer, its behavior might be impacted. For example, if the first timer performs some critical initialization or data preparation that the second timer relies on, and if the first timer times out before completing these tasks, it could lead to unexpected behavior or errors in the execution of the second timer.
In general, it's essential to design timers and their interactions carefully, considering dependencies and potential failure scenarios. Depending on your specific use case and requirements, you may need to handle such scenarios by implementing error handling, retries, or alternative mechanisms to ensure the correct behavior of your application.