Rules for using SDEJ Timers

There are some considerations and limitations to Generic Timer Bean provided as part of Cúram infrastructure and they are listed below.

1. SDEJ timers can invoke any client visible operation in the application meta-model, provided that:
   1. The operation has zero or one parameter.
   2. The operation has its Transactional option set to No.
   3. The user has access rights to that operation.
2. SDEJ timers do not have any facility to return a value from an operation.
3. Timer creation and cancellation are transactional; i.e., if you create a timer, it only becomes active after the transaction gets committed. Similarly if you cancel a timer, it only gets cancelled when that transaction gets committed.
4. Transactions invoked by timers execute using the same Cúram user ID as the user who created that timer.
5. The transaction type of a timer transaction is reported by TransactionInfo.getTransactionType() as being 'online'. (i.e. not deferred/batch/etc)
6. Timers should only be started by online transactions or other timer transactions. i.e. deferred processes, workflows or batch programs cannot start timers.
7. Timers are persistent and remain active until they are cancelled by the user, even if the application server is stopped and restarted.
8. If the application server is stopped for a time and then restarted later, all timers which were active before the shutdown will resume following the restart but the timer will not try to 'catch up' with any missed ticks. Instead it will tick at the next scheduled time.
9. If a timed operation throws an exception, the transaction will be rolled back. If the developer has specified a callback handler for the exception, the callback handler will get called if it has been configured, but it cannot be used to prevent the transaction from being rolled back.
10. If a timed operation throws an exception, the timer does not get cancelled and will continue to tick as before until it is cancelled from within a transaction which gets committed.

    Therefore it is important for developers to ensure that timed operations cannot repeatedly throw exceptions, as otherwise they could continue to be attempted indefinitely.

11. Timers should not be used to drive batch style processing. A timer driven transaction will have the same timeout as a deferred processing transaction (30 seconds by default) and should therefore be used only for reasonably short running pieces of processing.
12. Timers in the SDEJ are provided by the javax.ejb.TimerService of the application server. Currently it is not possible to start a timer from outside an application server which means that SDEJ timers are not available in the development environment. Attempting to start a timer from outside an application server will have no effect.