Design

Timer events enable an application to execute program logic at a specified time, after a specified amount of elapsed time, or at a specified interval. OTN developers used timer events in the FBS 10g to enable the system administrator to monitor trade activity. At a specified interval (for example, every 15 minutes), the system creates an email message listing the trades executed in that interval and sends it to the administrator. The administrator can set or change the interval at any time to receive updates more or less frequently.

Here are some points to consider when designing an application to use timers (from the EJB 2.1 specification proposed final draft 2):

• The EJB Timer Service is a coarse-grained timer notification service that is designed for use in the modeling of application-level processes. It is not intended for the modeling of real-time events.

• Timers can be created for stateless session beans, message-driven beans, and entity beans. Timers cannot be created for stateful session beans (although this functionality may be added in a future release of the specification).

• The timer service is intended for the modelling of long-lived business processes. Timers survive container crashes and the activation/passivation and load/store cycles of the enterprise beans that are registered with them.

• Timer durations are expressed in milliseconds because that is the unit of time granularity used by the APIs of the J2SE platform. It is expected that most timed events will correspond to hours, days, or longer periods of time.

In the FBS 10g, the Trade notification feature uses EJB Timers, because we need the notification for all time intervals. Even if the container crashes, we will need the notifications/list of trades for that interval. The data accessed by the timer is coupled with the trade details EJB.

As an alternative to the EJB Timer Service, the Java platform also provides the java.util.Timer (Util Timer) service, which allows threads to schedule tasks for future execution in a background thread. Because the Util Timer service uses a single background thread to execute all of the timer's tasks sequentially, it is best used with tasks that execute quickly. Also, this service cannot survive crashes, so tasks must be rescheduled.

In FBS10g, the Stock and News upload features use Util timers because they don't have to survive any crashes; the application just needs the latest rates. The data accessed by the timer was accessed using toplink and is not coupled with EJB's.