In this chapter, we will cover:
- Setting up the
ReportsApplication - Creating and using declarative timers
- Creating and using programmatic timers
- Understanding calendar-based scheduling
- Using the timer interface
- Using persistent and non-persistent timers
- Creating timers upon application deployment
- Using interceptors with timers
Many business functions are periodic in nature. For example, reports need to be generated, statistics need to be computed, and administrative cleanup tasks need to be performed; all on a regular basis. The EJB container's timer server supports time-delayed, asynchronous callbacks to an EJB to address these needs. An EJB will register with the timer service and a method will be called back.
Timers can be created for all EJB types except for a stateful session bean. Java EE 6 supports two types of timers: automatic and programmatic. Automatic timers are created using annotations. Programmatic timers are created using methods of the TimerService interface.
The callback methods of an EJB may be called:
- At a specific time
- After an elapsed period of time
- At specific intervals
The signature of a callback must use one of these two signatures:
void methodName()void methodName(Timer timer)
The second signature provides access to the Timer object that provides additional control and information about the timer. There is no restriction on the method's access modifier. It can be public, private, protected, or package level. However, the method cannot be declared as final or static and cannot throw application exceptions. The use of the Timer interface is discussed in the Using the timer interface recipe.
A callback method for an automatic timer is defined using either:
The Understanding calendar-based scheduling recipe discusses how to create a schedule for a timer. Once created, a timer can be cancelled using the cancel method. When it is cancelled, the callback method is no longer called.
Sometimes it is necessary to perform auxiliary operations such as logging or security when a callback method is executed. The use of interceptors, as detailed in the Using interceptors with timers recipe, facilitates this need.
Timers can be persistent or non-persistent. Persistent timers are able to survive application and server crashes. The Using persistent and non-persistent timers recipe covers this topic in more depth.
An application called, ReportsApplication, will be used in this chapter to illustrate the use of timers. The Setting up the ReportsApplication recipe details the steps needed to create the application.
A timer can be created in any number of different circumstances. The second and third recipes detail how to create a timer automatically and programmatically respectively. In the Creating timers upon application deployment recipe, singleton EJBs are used to create timers.
If a timer is involved in a transaction and an exception occurs, the transaction can be rolled backed. If a transaction is rolled back, then the creation of any timers will also be rolled back. If the timer is cancelled and its transaction is rolled back, then the cancellation of the timer is rolled back.
The timer service is not designed for use as part of a real-time application. The time duration used by the service is measured in milliseconds which is often inadequate for a real-time application. The timer service is designed for use with business applications where a time unit precision of hours, minutes, or seconds is sufficient.
Many of the examples used in this chapter are based on the "current" time. Feel free to change the time specified in the examples to a more appropriate value based on your needs.