EJB Timer Service: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 80: Line 80:
==Programmatic Timer Creation==
==Programmatic Timer Creation==


The [[#API|API]] allows programmatic creations of single-event timers, interval timers or a calendar schedule-based timers. The timer creation methods return a [[#Timer|Timer]] object that allows cancellation or obtaining information about the timer. By default, programmatically created timers are [[#Persistent_Timer|persistent]]. A [[#Non-Persistent_Timer|non-persistent]] timer can be created by calling <tt>setPersistent(false)<tt> on a <tt>TimerConfig</tt> object passed to a timer creation method.
The [[#API|API]] allows programmatic creations of single-event timers, interval timers or a calendar schedule-based timers. The timer creation methods return a [[#Timer|Timer]] object that allows cancellation or obtaining information about the timer. By default, programmatically created timers are [[#Persistent_Timer|persistent]]. A [[#Non-Persistent_Timer|non-persistent]] timer can be created by calling <tt>setPersistent(false)</tt> on a <tt>TimerConfig</tt> object passed to a timer creation method.


For single-event and interval timers, expiration may be expressed as duration in milliseconds or absolute time.
For single-event and interval timers, expiration may be expressed as duration in milliseconds or absolute time.

Revision as of 15:57, 25 September 2017

Internal

Overview

The EJB timer service is a container-provided service that invokes time-based callbacks into EJBs. The time-based callbacks can be invoked according to a calendar-based schedule, at a specified time, after a specified elapsed time, or at specified intervals.

The timer service is a coarse-grained notification service that is not intended to model real-time events.

Timer service callback invocations, and also those of methods used to create and cancel timers typically occur in a transactional context.

The timer service durations are expressed in milliseconds.

The timer service provides methods for programmatic creation and cancellation of timers, as well as for locating the timers that are associated with the bean. Timers can also be created automatically by the container at deployment based on the bean class or deployment descriptor metadata.

Timers can be created stateless session beans, singleton beans, message driven beans. They cannot be create for stateful session beans. The callback method invocation for a stateless session bean or a message-driven bean timer may be called on any bean instance in the pooled state.

The timer service is intended to serve long-lived business processes, timers survive container crashes, server shutdown and activation/passivation/load/store cycle of the EJBs that are registered with them.

Timer Service

Access

An EJB may access the timer service via dependency injection, by calling EJBContext.getTimerService() on the EJBContext interface or by looking it up in JNDI.

Dependency injection example:

@..

API

The timer service interface is specified by javax.ejb.TimerService.

Timer

A timer is an object created to schedule a timed callback. The EJB class that uses the timer service must provide one or more timeout callbacks.

For programmatically created timers, a timeout callback is a method annotated with the @Timeout annotation, or if the bean implements javax.ejb.TimedObject interface, the implementation of the ejbTimeout() method.

For timers that are declared, the timeout method is any method annotated with the @Schedule annotation.

When the time specified at timer creation elapses, the container invokes the associated timeout callback method of the bean.

A timer may be cancelled by a bean before its expiration by calling its cancel() method.

Client-specific information may be passed at timer creation (programmatic or declarative) to help recognize the significance of the timer’s expiration. The information object must be serializable.

Automatic Timer Creation

Timers are automatically created based on metadata in the bean class or deployment descriptor. This allows a developer to schedule a timer without relying on a bean invocation to programmatically invoke one of the Timer Service timer creation method. @Schedule and @Schedules annotations can be used for that.

By default, each @Schedule annotation corresponds to a single persistent timer, regardless of the number of JVMs across which the container is distributed.

Example:

@Schedule(hour="3", dayOfMonth="1", info="something")
public void toBeExecutedAt3AMOnTheFirstDayOfTheMonth() {
   ...
}

Multiple timers can be applied using the @Schedules annotation:

@Schedules(
{
    @Schedule(hour="3", dayOfWeek="Mon-Thu"),
    @Schedule(hour="4", dayOfWeek="Fri")
})
public void something() {
   ...
}

Programmatic Timer Creation

The API allows programmatic creations of single-event timers, interval timers or a calendar schedule-based timers. The timer creation methods return a Timer object that allows cancellation or obtaining information about the timer. By default, programmatically created timers are persistent. A non-persistent timer can be created by calling setPersistent(false) on a TimerConfig object passed to a timer creation method.

For single-event and interval timers, expiration may be expressed as duration in milliseconds or absolute time.

For calendar timers, the schedule is built via a ScheduleExpression instance using a builder pattern.

ScheduleExpression schedule = new ScheduleExpression().dayOfWeek("Sat").hour(1);
Timer timer = timerService.createCalendarTimer(schedule);

Persistent Timer

Non-Persistent Timer

A non-persistent timer is a timer whose lifetime is tied to the JVM in which it was created: it is cancelled by application shutdown or container crash.

The non-persistent timers are created by setting the "persistent" attribute of the @Schedule annotation to "false".