Java EE 6 allows developers to create application timers that are initialized when either a Stateless Session Bean, a Singleton Bean or a Message Driven Bean are deployed to the application server.

To indicate that a method on any of these beans is to be invoked on a timed basis, the method must be annotated with either the @Schedule annotation (for single timer schedules), or the @Schedules annotation (for multiple timer schedules).

The code below shows a very simple Stateless Session Bean configured with 2 scheduled timers. The first timer is configured with one schedule whereas the second is configured with 2 schedules.

package com.acme.timer;

import javax.ejb.Schedule;
import javax.ejb.Schedules;
import javax.ejb.Stateless;
import javax.ejb.Timer;

@Stateless
public class CalendarTimer {

  @SuppressWarnings("unused")
  @Schedule(second = "*/10",
            minute = "*",
            hour = "8-17",
            dayOfWeek = "Mon-Fri",
            dayOfMonth = "*",
            month = "*",
            year = "*",
            info = "Scheduled Timer")
  private void scheduledTimeout(final Timer t) {
    System.out.println(t.getInfo().toString() + " called at: " + new java.util.Date()); }

  @SuppressWarnings("unused")
  @Schedules({ 
    @Schedule(second = "15",
              minute = "*",
              hour = "8-17",
              dayOfWeek = "Mon-Fri",
              dayOfMonth = "*",
              month = "*",
              year = "*",
              info = "2nd Scheduled Timer"),
    @Schedule(second = "45",
              minute = "*",
              hour = "8-17",
              dayOfWeek = "Mon-Fri",
              dayOfMonth = "*",
              month = "*",
              year = "*",
              info = "2nd Scheduled Timer")
  })
  private void scheduledTimeout2(final Timer t) {
    System.out.println(t.getInfo().toString() + " called at: " + new java.util.Date()); System.out.println(); 
  }
}

As can be seen, the first timer is annotated with the @Schedule annotation. This annotation takes several parameters that define the timer schedule:

The table above shows the allowable values that can be used for each expression used to build up a schedule. These values can also be expanded into expressions to make more complex schedules.

Wildcard: A wildcard character (*) is used to indicate that the schedule will fire for every valid value of the specific operand. For example, setting the value second=”0″, minute=”*” would cause a timer to be invoked every minute at 0 seconds.

Lists: Comma separated lists of values allow timers to occur at every value in the list rather than at all valid values as specified by the wildcard character.  For example second=”0″, minute=”0, 15, 30, 45″ would cause a timer to be invoked every quarter of an hour.

Ranges: Hypen separated ranges allow timers to occur within the specified range.  For example dayOfMonth=”1-5″ would cause a timer to be invoked every day for the first 5 days of each month.

Intervals: Intervals are defined in the format start/interval and are valid only for hours, minutes and seconds.  An interval is defined as the start value for a timer and then the interval at which a timer will be invoked.  For example hour=”12/1″ would cause a timer to be invoked on the hour, every hour in an afternoon. It’s possible to combine the wildcard and interval expressions to cause a timer to be invoked every x hours, minutes or seconds.  For example  minute=”*/10″ would cause a timer to be invoked every 10 minutes.

The second method in the example above shows how 2 different schedules can be applied to a timer.  In this instance, the method is annotated with the @Schedules annotation rather than the @Schedule annotation.