On Jan 30, 2013, at 3:07 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
> On 30.01.2013, at 20:54, Bill Burke <bburke_at_redhat.com> wrote:
>
>>
>>
>> On 1/30/2013 11:32 AM, Marek Potociar wrote:
>>> I'm not sure I follow how the EJB async "fire-and-forget" nature relates to HTTP.
>>
>> Exactly my point, it doesn't relate, so you can't use it with JAX-RS. HTTP expects a response, 'void' + @Asychronous, there is no response for EJB clients.
>>
>>> All we are saying is that the HTTP response is returned on a different thread that the one received the request.
>>
>> Back to our old argument, so I won't go there...
>>
>>> Async EJBs is one way how to delegate request processing to another (managed) thread in a JEE container.
>>
>> Wrong. Async EJBs is so that the client execute one or more tasks in the background. It has nothing to do with managed threads in the Java EE container other than a possible implementation detail.
>
> Aha - that would explain why EJB does not provide a way to select the thread pool for the new thread in @Asynchronous. I found that to be really missing from a design POV. Not implying a new threads explains that.
Actually, there will likely be changes to the EJB spec with the introduction of JSR 236. The idea of "surfacing" rather than "hiding" threads is becoming more important with 236.
-- Santiago