geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Thread Pool vs WorkManager
Date Tue, 16 Aug 2005 18:24:22 GMT
	Hmm... I don't like that there are two different classes of thread
pools in Geronimo.  I'd like to have one set to manage and modify.  If we
feel strongly that OpenEJB should use a different interface, can we make
it so a Gernoimo J2CA WorkManager automatically exposes an Executor
interface too so that OpenEJB can use the same object, even if exposed via
a different interface?

	Then if the other JSR WorkManager thing gets off the ground, maybe
later we can base the implementation on that and have it expose both J2CA
WorkManager and Executor interfaces to other parts of the system.

Aaron

On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> They have different purposes.  The WorkManager is a lot more  
> powerful, but most server environments either don't have one or don't  
> have a publicly available implementation.  I would prefer that if  
> service does not need a work manager, it does not use one.  This will  
> allow a service to run in more environments.
> 
> As for how the default Geronimo server is configured, I would prefer  
> that we always use WorkManager.
> 
> -dain
> 
> On Aug 16, 2005, at 11:06 AM, Aaron Mulder wrote:
> 
> >     I guess what I was saying was, let's pick one abstraction and go
> > with it.  It seems weird to have half the threads managed via thread
> > pools, and half managed by work managers.  If we agree that work  
> > managers
> > are the way to get, we can use an adapter like you suggest to make  
> > OpenEJB
> > work with a work manager, and then dispense with the thread pools  
> > in the
> > server configuration.  Is that OK with everyone?
> >
> > Aaron
> >
> > On Tue, 16 Aug 2005, Dain Sundstrom wrote:
> >
> >> I don't think it is a big deal to use a concurrent Executor, since it
> >> is a subset of WorkManager.  Executor has one method:
> >>
> >>      public void execute(java.lang.Runnable command)
> >>
> >> which maps easily to:
> >>
> >>      public void scheduleWork(Work work)
> >>
> >> Now, we just need WorkManagerExector and RunnableWork classes :)
> >>
> >> -dain
> >>
> >> On Aug 16, 2005, at 8:30 AM, Thomas P. Fuller wrote:
> >>
> >>
> >>> Aaron,
> >>>
> >>> Ok I'm not an expert on the internals of J2EE
> >>> architecture, but I'm going to give my .02$ here
> >>> regardless and you can beat me up if/when you
> >>> disagree:
> >>>
> >>> I think the standardization should be on the work
> >>> manager api since it's purpose is to provide "...a
> >>> concurrent programming API for use within managed
> >>> environments on the Java TM platform, such as Servlets
> >>> and EJBs" (I'm quoting directly from the paper
> >>> Commonj-TimerAndWorkManager-Specification-v1.1).
> >>>
> >>> Using the work manager api also seems to make for a
> >>> more sound architecture since the responsibility of
> >>> task execution would be left to the api and would
> >>> remove the requirement to maintain this logic in more
> >>> than one place.
> >>>
> >>> Finally, it would seem appropriate that a future
> >>> enhancement to the OpenEJB impl could involve the
> >>> removal of the thread pools, replacing it with
> >>> delegation of task execution directly to the work
> >>> manager api; this is speculation and off topic,
> >>> however, and so I won't continue.
> >>>
> >>> Thomas
> >>>
> >>
> >
> 
> 

Mime
View raw message