1

I have 4 methods in my Timersession bean,lets say a(), b(), c() and d().

  • a() should be executed every 6 hour
  • b() should be execute every 3 hour
  • c() should be execute every 1 hour

How can I do this by using EJB 3.0 timer service?

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
yagnya
  • 549
  • 1
  • 4
  • 18

2 Answers2

2

Schedule three separate timers, and use the "info" object to encode which method needs to be called from the @Timeout method. For example:

timerService.createTimer(..., 6 * 60 * 60 * 1000, "a");
...
timerService.createTimer(..., 3 * 60 * 60 * 1000, "b");
...
timerService.createTimer(..., 1 * 60 * 60 * 1000, "c");
...

@Timeout
private void timeout(Timer timer) {
  String info = timer.getInfo();
  if ("a".equals(info)) {
    a();
  } else if ("b".equals(info)) {
    b();
  } else if ("c".equals(info)) {
    c();
  } else {
    throw new IllegalStateException("Unknown method: " + info);
  }
}
Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • Why? It makes sense for independent events to have independent Timers. You might be able to derive the desired method from Timer.getNextTimeout, but it will be convoluted. – Brett Kail May 03 '11 at 05:24
1

Definitely, you can create multiple timers & can handle it in a single method.

Sample code :

//--

    @Schedules ({
        @Schedule(hour="*/1"),
        @Schedule(hour="*/3"),
        @Schedule(hour="*/6")
    })
    public void timeOutHandler(){

        if(currentHr % 1 == 0)  //-- Check for hourly timeout
            a();
        else if(currentHr % 3 == 0) //-- Similarly
            b();
        else if(currentHr % 6 == 0) //-- Similarly
            c();
    }

//--
Nayan Wadekar
  • 11,444
  • 4
  • 50
  • 73
  • How does the code obtain currentHr? For persistent timers (which are the default), catch-ups can be run at arbitrary times, so current system time won't work; Timer.getNextTimeout could be used, but that's messy. I think using info="" would be best. (I assumed in my answer that the ejb-3.0 tag meant that EJB 3.1 constructs weren't allowed, but I certainly agree that @Schedule is nicer than interacting with TimerService directly.) – Brett Kail May 03 '11 at 19:29
  • @bkail - i have provided sample code, not the complete implementation. currentHr is just a variable indicating current hour in 24hr format & timers are based on calendar-based expressions, working with current system time should not be an issue i think. – Nayan Wadekar May 03 '11 at 19:44
  • That's my point: the system clock only indicates when the timer actually fired rather than when the timer was supposed to fire. The two can be arbitrarily different, so calculating which method to call based on the current timer is not reliable. – Brett Kail May 04 '11 at 05:49
  • yes, there might be difference in time, but that would be probably in minutes, & here we are considering hours. I have found timer service reliable enough. I have only tried to figure out the way differently, else what you have suggested is better. – Nayan Wadekar May 04 '11 at 18:39