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
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
>
