geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Thread Pool vs WorkManager
Date Tue, 16 Aug 2005 18:01:53 GMT
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
>>
>


Mime
View raw message