geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 00:38:04 GMT
Here's another way to think of it.  Quartz is a Job container, just
like Tomcat is a Servlet container and OpenEJB is an EJB container.


On 6/11/06, Jeff Genender <> wrote:
> Why would you want Jobs based GBeans?  This makes no sense to me.  Those
> are innately Quartz objects in their own right. IMHO, everything does
> not need to be a GBean...especially when working with 3rd party
> components.  I am personally against Jobs being GBeans...
> I would leave every thing underneath Quartz as "native" Quartz as possible.
> Just my .02.
> Jeff
> 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.
> >
> > 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?
> >
> > 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.
> >
> > Thanks,
> >     Aaron

View raw message