Yea, the problem is that it's running in the Servlet tier.
And I know that in many cases there is little distinction between the Servlet tier and that App tier, but there is in fact a difference. And while EJB Timer has "issues", it DOES run in the App tier, and not the servlet tier. So, if I had an application that is a truly remote application tier, (i.e. all the clients communicate through RemoteSessionBeans, etc.), then I would need a local empty web app on the application tier to simply run Quartz.
So, it's more a separation of the two tiers and wanting job scheduling in the application tier.
You can argue that it's moot, I mean, just put the Quartz threads in the Servlet tier and have them call Session Beans to do all the work.
So it's a matter of taste. I would prefer that the scheduling be done in the app tier, letting the server manage those threads like it does everything else, rather than having to configure Quartz in its own way to manage these things.
I imagine, the "best" way to integrate Quartz in the app tier would be perhaps creating a JCA wrapper around it, or perhaps as a GF specific AMX module. But I don't quite know how that all works.
EJB Timers, if they fit within your model, are pretty darn trivial to use.
We leveraged EJB Timers and JMS queues to make a generic Task Model that lets us schedule and run tasks, and the tasks can either run synchronously (all at once), or splatter the work across a cluster of servers (using JMS and MDBs) if your units of work can truly work in parallel. Even on a single machine, we've seen 2-5 times speed ups for brain dead IT work when we parallelize it using the JMS queues on high end hardware like Mac Laptops and generic Dell Towers. T2000 anyone?
Whoo boy...
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=223621