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 19:26:36 GMT
	Do you think it's appropriate to have a Geronimo configuration 
that includes J2CA WorkManager thread pools and other thread pools?  If 
so, how do you present it to a user?  "Thread Pools: J2CA" and "Thread 
Pools: Other"?  This seems silly.

	Or are you saying that we should manage all our thread pools as
"just thread pools" and make our J2CA WorkManager a wrapper around a plain
thread pool?  That way you'd still manage all the thread pools in one
place ("Thread Pools") and then in the WorkManager configuration you'd
point a work manager to an existing thread pool it should use.  I'm OK
that way too -- I just don't like having two separate pools of thread
pools for no particularly good reason.

Aaron

On Tue, 16 Aug 2005, David Jencks wrote:

> I'll repeat that IMO it is really inappropriate to use a J2CA work 
> manager where a thread pool/executor would suffice.
> 
> IIRC we could base a j2ca work manager on the proposed non-j2ca work 
> manager, but they have really different purposes.
> 
> david jencks
> 
> On Aug 16, 2005, at 11:24 AM, Aaron Mulder wrote:
> 
> > 	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