geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Thread Pool vs WorkManager
Date Tue, 16 Aug 2005 18:02:56 GMT
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.


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

View raw message