prefer to create them programmatically instead of having to deploy them.
IMaybe the deployer should only create the job and let quartz store it in the database.
The only problem is that when the job is undeployed, you have to remove it from the
database. But afaik, you have no simple way to know that a gbean is undeployed
(you can only know when a gbean is stopped). Another thing that would be needed
is to know when a gbean is stopped manually and not as part of a server shutdown,
so that you can deactivate the job without having to deactivate / reactivate
them each time the server is restarted (this is the kind of problems that I have been facing
with ServiceMix). All these problems do not happen if you only keep the job in the gbean and
not in the database.
Btw, imho, a quartz integration should leverage xa transactions so that job creations and job
executions can be enlisted in a transaction.
Cheers,
Guillaume Nodet
On 6/13/06, John Sisson <[EMAIL PROTECTED]
> wrote:
Aaron Mulder wrote:
> On 6/11/06, Alan D. Cabrera < [EMAIL PROTECTED]> wrote:
>> I think that there is an important distinction here. There's a
>> difference
>> between providing JMX access and what features deployment
>> capabilities have.
>> For example, while I may have access to an individual instance of an
>> entity
>> bean, I'm not sure because, thank god, I do not know JSR-77, I am
>> certain
>> that one cannot *create* an instance of an entity bean using GBean.
>> One can
>> only create its container.
>
> I'm not sure what the distinction is. If you deploy a EJB JAR full of
> classes and XML, the end result is that the EJB container runs EJBs.
> I'm suggesting that if you deploy a "jobs" JAR full of classes and
> XML, the end result will be that the scheduler runs jobs.
>
> Thanks,
> Aaron
>
How scalable would this be? I would imagine there would be applications
that may create thousands of jobs (possibly per day). Wouldn't startup
be slow if we had to de-serialize thousands of jobs at startup in the
process of loading all the GBeans that represent the jobs. Not having
looked at quartz myself, it seems it would be much better to have jobs
in a database. For example, thousands of Jobs could be created that
aren't to be executed until next year. I would expect that a job
management engine would optimize processing, e.g. only read jobs from
the database into memory that are to be executed today or in the next hour.
John
