We are currently looking at Activiti for handling approval events in our organization, but we are looking to build the REST API within a containerized environment*. The containerized tomcat instances will be sharing a persistence layer, but due to the ephemeral nature of the instances, we can't have any state maintained by Activiti.
We don't envision this to be a problem but for the timed boundary events, and it ties to a wider question about how Activiti Timers work. Is the execution of the timer a function of a date/time expression kept in the (permanent) persistence layer (thus it's evaluated when the engine interacts with that expression)? Or is it a process that keeps a running clock and then fires when it expires? The latter of the two is not preferable, but if that is the case, how does one recommend we keep track of boundary timers when the Activiti layer is impermanent?
*(using ephemeral Tomcat layers that can be blown away at any time)
Really good question and I'd be really interested in the architecture you come up with.
Timer events are processed by the Job Scheduler. In more recent versions of Activiti (>5,16 I believe) the Timer and Async queue managers have been separated but they still use the same underlying data table (ACT_JOB).
Each Job Executor will tag a block of timer events whose time is past due and put them into the timer queue for processing. You can set the number of tasks picked up each pass as well as the timeout and queue size in the engine configuration.
So, to your specific question: " Is the execution of the timer a function of a date/time expression kept in the (permanent) persistence layer (thus it's evaluated when the engine interacts with that expression)? Or is it a process that keeps a running clock and then fires when it expires? "
The Timer ACT_JOB table holds a DueDate (DateTime) which the Timer thread will use when it queries the next set of jobs to process. Which, if I understand your language is a variation of option 1.
Greg
"