On Aug 16, 2005, at 12:26 PM, Aaron Mulder wrote:
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.
I think having the j2ca work manager reference an external thread
pool(s) would be fine. I've thought about it but never implemented it.
thanks
david jencks
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
