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
