geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 00:20:08 GMT

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.


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