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
