Home/ Questions/Q 7026423
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T00:06:55+00:00

Our shop currently uses Quartz for our existing projects. The only draw back is

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0