Different Java EE application servers implement their timer mechanism in different ways and there is no standard way to administer timers via their admin consoles. The TimerInfo API provides a number of functions to find and query active timers.
A single-event timer will stop automatically after one successful execution. (i.e. if it executes a transaction which committed successfully.) For repeating timers, the TimerInfo class contains a number of methods for stopping these timers. Note that stopping a timer will only take effect when the transaction which requested the stop is committed.
Cúram timer beans can only invoke methods which are in the model and are client visible, therefore it is possible for the HTML client to also access these methods, which may not be desirable.
If you want to ensure that only only a timer transaction executes your method, you can use the TimerInfo API to check for this at run time as illustrated by the following sample code extract:
// Ensure that this transaction is a timer: if (!TimerInfo.isTimerTransaction()) { // throw an exception to report that an // invalid attempt was made to execute // this operation outside of a timer. throw new AppException(....); }
The Cúram timer bean API is a wrapper for the Java EE Timer API and it is worth noting that the Java EE Timer API uses arrays of timers and as such is not designed for dealing with very large volumes of timers.
As an extreme example: if an application contained several million customer records on the database, it would be unadvisable to use timers as the mechanism for controlling when an invoice is issued to each customer, because this would result in having several million timer objects active in memory.
In general it is recommended that timers be kept as few and as short lived as possible.
The parameters used when creating a timer allow a developer to specify a granularity of milliseconds with regard to when and how often the timer will fire. However the application server cannot guarantee to fire the timer at exactly the expected time because there may be conditions which prevent this from being achieved. For example the server may be down at the scheduled time, it may be delayed by other transactions, a large number of timers may be scheduled to fire at exactly the same moment, etc. The rule of thumb is that the application server will fire the timer event as close to the designated time as possible, so the developer should not assume that the timer will fire at an exact time.
No. Currently timers only operate in deployed applications because the underlying implementation is provided by the application server.
Timers cannot be executed in the development environment as this is currently not supported. However Cúram timers can output extensive logging data if required. The fact that each timer has a unique identifier means that its execution and life cycle can be traced via the log output.
This logging data can be captured by configuring a log4j appender for category 'Trace.TimerInfo'.
No. The life cycle of a timer is controlled by the developer. i.e. the developer is responsible for starting each timer and for ensuring that it stops.