Find attached a simplified model regarding the issue.
** Behavior **
Every time we loop back to the timer task a new row is added to the ACT_RU_JOB table. The prior timer due-date row is not removed but appears to be executed anyway because RETRIES_ is reduced to 0 and there is a value for EXCEPTION_STACK_ID.
This "old row causes exception" behavior seems consistent within unit tests as well. To unit test my model I have a ManagementService query for timers. Calling executeJob for any Job but the most recent entry causes an exception.
** Model **
We are using a repeat timer "<timeCycle>R/T02-07/P1D</timeCycle>" to have instances check external business state while server load is low (regardless of when the instance actually started). Depending on state, each instance may either; transition to one of two UserTasks, or circle back around to the "daily timer"
** Questions **
1) It seems the every-growing ACT_RU_JOB table with its evidence of exceptions will incur a performance penalty for large numbers of long-running instances. Am I doing something wrong with the timer spec?
2) Should I use something different to achieve the run "once-a-day-at-0200" behavior? (I've avoided using a BoundaryTimer because the designer keeps hosing the model).
