geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 00:07:33 GMT

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


Mime
View raw message