I haven't looked into the code here, but anyway...
There are at least 2 work manager concepts
--j2ca 1.5 WorkManager, which includes stuff like transaction import.
This is not appropriate for use as a plain thread pool
--jsr ??? AFAIK unapproved WorkManager proposal, which is a reasonable
interface for a thread pool. IIRC someone planned to provide an
implementation of this but I haven't seen anything yet.
Can you guys be a little more precise about which WorkManager concept
you are discussing?
thanks
david jencks
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
