5

Our shop currently uses Quartz for our existing projects. The only draw back is that Quartz threads are run unmanaged.

We are moving to EJB 3.1 and I was wondering if there is any way to replicate the dynamic nature of Quartz job scheduling. Specifically, I would like to know if anyone has heard of someone writing a GUI front end to handle, manage, or edit jobs using EJB 3.1.

From what I've read, this seems either impossible or very cumbersome. It seems that EJB 3.1 timers are private to the bean they reside in, making the process of collecting them and examining them rather difficult. Also, it seems that EJB 3.1 timers are purely programatic/declaritive, i.e. they require a redeploy to modify their parameters or settings.

Any thoughts, ideas, or experience in this arena?

Last note, we are using Websphere 8.0.

Brett McLain
  • 2,000
  • 2
  • 14
  • 32

1 Answers1

6

It seems that EJB 3.1 timers are private to the bean they reside in, making the process of collecting them and examining them rather difficult.

This is unfortunately indeed the case, see my answer to a similar question here: How to get all EJB timers?

Also, it seems that EJB 3.1 timers are purely programatic/declaritive, i.e. they require a redeploy to modify their parameters or settings.

Well, from within the bean where you scheduled timers you can cancel a timer and re-schedule it if you wanted to.

All in all, after using EJB 3.1 timers for a while now I can say they are very convenient, but there are still a couple of omissions. The problem you mention here is one, but there is also no portable way to specify where timers are persisted. Actually, there is often no way at all to do this from within a project. In Quartz this is no problem.

Community
  • 1
  • 1
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • 1
    Just to make it complete - a link to [EJB 3.2 spec request regarding persistence](http://java.net/jira/browse/EJB_SPEC-45). Voting and/or discussion is always nice ;-) – Piotr Nowicki Dec 31 '11 at 12:18
  • 2
    Indeed, thanks for the participation :) It would be a good idea to also create an issue for discovering all timers. – Arjan Tijms Jan 02 '12 at 21:12
  • 2
    And there it is :-) [Discovering all timers within the container](http://java.net/jira/browse/EJB_SPEC-47) – Piotr Nowicki Jan 02 '12 at 22:53
  • This might be a stupid question, but would it be possible to dedicate an EJB to managing all the timers for the entire container? I don't know how this would be accomplished as I'm not all that experienced with Java EE, but I'm thinking something along the lines of individual session beans having access to this timer bean, and the session beans pass in a function pointer along with the meta data for the job itself? On top of the timer bean, it would then be possible to build a GUI or management framework to, at the very least, see what jobs are running and their current status? – Brett McLain Jan 03 '12 at 19:57
  • @Sparticus, I guess that right now the container (after scanning of the `@Schedule` annotations and programmatic added timers) creates such kind of central place / storage for all the timers. In my opinion, if the TimerService would be a separate entity it would be easier to access and manage it. – Piotr Nowicki Jan 07 '12 at 10:23