geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 00:20:41 GMT
I agree w/ both DJ and Jeff.


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