geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: GBeans representing separately persistent data
Date Mon, 12 Jun 2006 18:16:04 GMT
Still reading this thread, but lots of cool ideas in this email.   
Would be cool to use something like this in gbuild -- bunch of  
directories hot-deployed containing the various jobs we run.


On Jun 11, 2006, at 5:34 PM, Aaron Mulder wrote:

> I looked at the developerworks article.  The GBean there is extremely
> simple.  It starts a Quartz scheduler, but has no code or methods to
> configure it or do anything with it.  I think it was more a
> demonstration of how to write a GBean than anything else.
> As for why I wanted to represent jobs as GBeans, it's so you can
> deploy and manage them.  That is, you can deploy a job, start it, stop
> it, or undeploy it, as well as managing its schedule, executing it
> immediately, querying the last time it ran and the next time it'll
> run, etc.  Since it's a unit that can be deployed and managed, it
> seemed logical to represent it as a GBean.
> I guess the alternative you're suggesting is to expose the scheduler
> as a GBean and if you want to do anything with jobs you have to
> interact with the scheduler GBean and call methods on it.  That would
> work, but I don't think it's as nice in practice.  For one thing, I'm
> not sure how you'd get the job classes to the scheduler -- it seems
> like you might need to alter the scheduler module to add more
> dependencies every time you added new jobs -- at least if you were
> using a database for job persistence.  Also, if you want to add a job,
> you need to write some kind of code to access the scheduler and add
> the job, which seems a little onerous.
> With the job-as-GBean approach, in contrast, you can pack your job
> classes in a JAR with a plan that defines the schedule, and deploy
> that using the normal Geronimo deployment tools.  Then in addition to
> convenient deployment, they each get their own class loader, and can
> declare dependencies on other application modules (e.g. to get the
> classes necessary to call a session bean).
> Thanks,
>    Aaron
> On 6/11/06, David Jencks <> wrote:
>> 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

View raw message