Timers

The progression of Enterprise JavaBeans and J2EE standards into a robust platform has been further improved in version 2.1 with the introduction of a standard timer service. The timer service, somewhat analogous to the UNIX cron mechanism, allows notifications and services to be invoked based upon a timer that is configured within the J2EE environment.

The timer service is a new container-provided service that is used for a reliable and transactional notification mechanism for the EJB component model. The timer service can be used with stateless session, message-driven, and entity beans.

The timer architecture follows a publish-and-subscribe design. At a high level, the bean instance that wishes to be called back at a particular time implements the TimedObject interface, which provides a single ejbTimeout() method. The bean accesses the timer service via the EJBContext. A timer is then created and registered via the service. It is the responsibility of the container to manage the timer and at the expected time invoke the callback method ejbTimeout() of the bean instance.

Timers can be created using two categories of parameters, namely, expiration and interval, and can use a combination of both. The expiration parameter configures the callback invocation to occur at a specified time. For example, next Thursday, June 30, at 5:00 p.m.

The interval parameter configures the callback invocations to occur at specific intervals, for example, to execute every fifteen minutes. A timer can use a combination of these parameters to run at specified intervals, beginning at a particular expiration time. For example, execute next Thursday, June 30, at 5:00 p.m., and every fifteen minutes thereafter.

Timers are very useful for workflow applications, data maintenance, and for monitoring applications and batch jobs. Some examples of using the timer service are the following:

• A Payroll EJB component is notified and run every fifteenth day of the month to process the payroll of the company.

• An AccountsReceivable EJB component is invoked at the end of each business day to e-mail all customers whose accounts are overdue.

• An OrderProcessing EJB component is invoked after a sleep interval of an hour between each processing run. This component queries an incoming order table of a database and processes each order.

• A SystemsManagement EJB component is invoked every fifteen minutes to check the availability and performance of a database and external web service.

• A Customer EJB component is invoked at the end of each business day to archive customer records that have not been used for the past twelve months.

The timer service is integrated into the EJB component model architecture and makes use of the security, persistence, and transaction standards used with the container as follows:

• Security: Timed callbacks are invoked by the container and not directly by a calling client; the security model for timers uses the <run-as> setting in the deployment descriptor to set security information. Use of this tag was previously described in Chapter 8, "Security," and the example later in this section shows the use of the setting for timed objects.

• Persistence: The container provider implements the timer service and must provide persistence of timers as part of the service. This involves ensuring that any timers that are registered before a server crash or restart are reregistered, and any timers that should have been invoked while the server was unavailable will be invoked. This contract holds true for timers with expiration or interval parameters.

• Transactions: The timer service is transactional; this means that the registration and cancellation of timers, as well as the invocation of the timer callbacks, can be affected by transactions. If timers are registered or canceled within the scope of a transaction and the transaction is rolled back, then the timer operation is also rolled back. In this case, the timer will not be registered, and the cancellation will be undone. The EJB specification recommends setting the transaction attribute (described in Chapter 7, "Transactions") to RequiresNew for ejbTimeOut methods. If the transaction attribute is set to RequiresNew, upon timer invocation, if the container's invocation receives a transactional rollback, then it will retry the timeout callback.

The reader should note that the EJB specification specifically mentions that the timer service is not for real-time event processing, and the specification makes specific note that if multiple timers are registered to a particular bean at almost the same time, the invocations may occur out of order.

As mentioned earlier, only stateless session, message-driven, and entity beans can respond to timer events by implementing the TimedObject interface. Stateful session beans are prohibited from implementing the TimedObject interface. Timers are both persistent and transactional, and they can be canceled after their creation. The timer service consists of the interfaces shown in Figure 10-5.

Figure 10-5: The interfaces of the timer service.