On Jun 11, 2006, at 4:20 PM, Aaron Mulder wrote:
So I've been playing around with a Quartz integration plugin. My
first stab only supported an in-memory schedule, but Quartz also
supports storing to a database. Here's my issue with that.
Right now I have a GBean representing a scheduled job. When you start
it, the job is scheduled. When you stop it, the job is deleted.
Therefore when you start the server, the scheduler is started and the
deployed jobs are started, and I guess they're effectively persistent
using config.xml as storage instead of using a DB.
I've never used quartz but the idea of a job as a gbean seems odd to
me. I would expect there would be one quartz gbean and everything
you scheduled would be saved in a database. Can you provide a lot
more detail about what the job gbean is like? So far I don't get it,
it seems like extreme impedance mismatch.
So let's say we let you store the job info to a database. What
happens to the job GBeans? You can take down the server, delete all
your jobs from config.xml, add some new jobs to the database, and
start the server again. So the GBeans can get totally out of sync
with the data they represent.
I guess what would be most appropriate for this case would be some
kind of "transient GBean" that does not save to config.xml. So when
the scheduler starts it could create GBeans representing all the jobs,
which you could use to manage it, but changes to the GBeans would only
affect the Quartz database (not config.xml) and when you shut down
they'd all go away. Until next time you start up, and the scheduler
would recreate all the job GBeans again. What do you think?
I don't get why these are "gbeans". I must be missing something
important here.
The alternative is to keep using GBeans as persistence, and just add
GBeans to represent calendars and triggers, which are the other two
fundamental types in Quartz. That certainly seems like the more
expedient path for now.
I also don't understand why these other types would be gbeans
either. I'd really appreciate more detail on this. This could well
be the best model, but I don't see why yet :-)
BTW I thought jeff already did a quartz integration, in a
developerworks article, have you looked at what he did?
thanks
david jencks
Thanks,
Aaron
