Simplest Possible EJB 3.1 Timer - Configured Programmatically

@Singleton @Startup public class PeriodicTimer { @Resource TimerService timerService; @PostConstruct public void initialize(){ ScheduleExpression expression = new ScheduleExpression(); expression.second("*/1").minute("*").hour("*"); timerService.createCalendarTimer(expression); } @Timeout public void execute(){ System.out.println("----Invoked: " + System.currentTimeMillis()); } }

 

A timer doesn't have to be a singleton - it can be a @Stateless and even a @Stateful bean. The method execute() will be invoked every second after the deployment. The programmatic registration is only an option. You could also use annotations for the timer configuration.

How to compile:

You will need the EJB 3.1 API in the classpath (few kilobytes).

How to deploy:

Just JAR or WAR the interceptor with an EJB and put the archive into e.g: [glassfishv3]\glassfish\domains\domain1\autodeploy

Btw. the initial deployment of the entire WAR took on my machine:


INFO: Loading application ProgrammaticallyCreatedTimer at /ProgrammaticallyCreatedTimer
INFO: ProgrammaticallyCreatedTimer was successfully deployed in 316 milliseconds..

How to use:

Another service can be easily injected to the timer and so invoked periodically:

@Stateless
public class HelloService {
    public String sayHello(){
        return "Hello from control: " + System.currentTimeMillis();
    }
}

And: there is no XML, strange configuration, libraries, additional dependencies needed...You will find the whole executable project (tested with Netbeans 6.8 and Glassfish v3) in: http://kenai.com/projects/javaee-patterns/ [project name: SimpleTimer].

[See also "Real World Java EE Patterns - Rethinking Best Practices"] 

Comments:

Thanks for this post. I just looked at the JavaDocs and see that TimerService's create methods can take a TimerInfo object, which can hold a Serializable object that holds contextual information. Some of the create methods can take a Serializable object directly. This is what I was looking for. Thanks

Does anyone with Quartz experience know how it compares with Java EE 6's TimerService in a non-clustered environment, and a clustered environment?

Posted by Ryan de Laplante on February 22, 2010 at 12:33 PM CET #

Ryan, normally the scheduler will be kept consistent among the cluster. So every event should only be fired once, not once for every node in the cluster.

I doubt you can fully compare Quartz as a timer service to the JEE6 scheduler, since Quartz is in a league of it's own(more trigger options, calendar options etc etc...).

Posted by Lieven Poelman on February 23, 2010 at 03:18 PM CET #

I think souce codes do not fully coresponds each other ...

I can not see how can be HelloService injected to the timer

Posted by Petr Klíma on February 26, 2010 at 10:48 PM CET #

Thanks Man

Posted by 204.194.77.3 on January 24, 2014 at 04:33 PM CET #

Thank you, Adam!

Posted by Mircea on March 29, 2014 at 06:33 PM CET #

Hi Adam,

nice TimerService example! We still use Quartz in most of the historically grown Java web applications in our business unit, but want to switch to TimerServices.

The problem I actually see is to configure the TimerService dynamically be our operations team. Normal use case in our applications is to use a property file and reconfigure the cron expression to set a new timer interval in Quartz.

Is there any possibility to parse a cron expression and convert into a ScheduleExpression without reprogramming all the Quartz logic? The requirement is to adhere on the property mechanism to be able to configure the timer wichout redeploying the application (so no @Schedule(...)).

Is there any lightweight solution for this issue?

Thank you!

Posted by Stephan on February 24, 2015 at 10:56 AM CET #

Thanks, This is very helpful

Posted by Ahmed on October 30, 2016 at 07:40 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments
License