geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: GBeans representing separately persistent data
Date Tue, 13 Jun 2006 03:11:14 GMT
Aaron Mulder wrote:
> On 6/11/06, Alan D. Cabrera <list@toolazydogs.com> 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

Mime
View raw message