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 19:00:26 GMT
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
>>>>>
>>>>
>>>
>>
>>
>


Mime
View raw message