jsr345-experts@ejb-spec.java.net

[jsr345-experts] Re: Asynchronous *Client* Invocation Semantics

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Tue, 05 Jul 2011 16:05:37 -0700

Does somebody from the EJB 3.1 EG remember why the original approach was
abandoned when an EJB could have a regular return type on its async
method, with a Future return type on the corresponding method on an
interface?

thanks,
-marina

Carlo de Wolf wrote:
> It brings us back to the original problem of the async API: you want
> the app developer to use Future, but Future is not used in the
> business interface definition. This makes no real difference for void
> methods (if you're not interested in exceptions), but other methods
> should 'return' a Future. Hence the divine() method.
>
> Carlo
>
> On 07/01/2011 02:38 PM, Pete Muir wrote:
>> I do agree with Carlo that often it is the client that knows whether
>> an invocation should be sync or async.
>>
>> I also agree with Reza that the proposed syntax is a little obtuse.
>> Some comments:
>>
>> * I don't like the use of static helper methods at all, it's
>> (a) clunky and
>> (b) inconsistent with the rest of Java EE
>> * Where possible the API should avoid having classes in it
>> * I don't really understand the naming of the methods beyond async()
>>
>> public class Async {
>>
>> public static<T> T async(T bean);
>>
>> public static Future<?> divine();<<< What does divine() mean?
>>
>> public static<R> Future<R> divine(R dummyResult);
>> }
>>
>> I would have thought that it is more consistent with the EJB
>> component model to expose a special JNDI name returning an async or
>> future wrapped version of the bean. With CDI we could then expose
>> these as @Asynchronous and just future wrapped options.
>>
>> e.g.
>>
>> @Inject @Asynchronous SomeBean bean;
>>
>> @Inject Future<SomeBean> bean;
>>
>> On 30 Jun 2011, at 19:18, Reza Rahman wrote:
>>
>>> Personally, I think @Asynchronous is fine (in fact, I think it is
>>> probably more intuitive than the proposed syntax). The cases are
>>> very rare that a synchronous method would suddenly be used
>>> asynchronously without the bean developer's knowledge. It's also the
>>> case that in order to support things like cancellation, the bean
>>> would have to be aware that it is being invoked asynchronously.
>>>
>>> Cheers,
>>> Reza
>>>
>>>
>>> On 6/30/2011 1:57 PM, Marina Vatkina wrote:
>>>> Thanks for asking. The official guideline is to use this list :)
>>>>
>>>> -marina
>>>>
>>>> Pete Muir wrote:
>>>>> Where should we discuss this - comments thread? email list?
>>>>>
>>>>> Marina, what is the official guideline?
>>>>>
>>>>> On 30 Jun 2011, at 09:59, Carlo de Wolf wrote:
>>>>>
>>>>>> As I mentioned on the EJB 3.1 EG when we did asynchronous, I
>>>>>> don't like that it is tied into the bean developer realm.
>>>>>>
>>>>>> I've opened up http://java.net/jira/browse/EJB_SPEC-11 as a
>>>>>> proposed alternative.
>>>>>> Looking forward to your comments.
>>>>>>
>>>>>> Carlo
>>>>
>>>> -----
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 10.0.1388 / Virus Database: 1516/3735 - Release Date:
>>>> 06/30/11
>>>>
>>>>
>