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
