I'm not sure it'd be a simplification.... :(
What would be the business case for the client side decision on sync vs.
async method calls? What type of clients will they be? With a local
client, the bean developer will need to be aware that depending on a
client decision, the method will be executed in the same or in the new
transaction...
-marina
Pete Muir wrote:
> Hmm, I really can't see a better way to do this.
>
> In conclusion, I definitely see the need for this, but not in love with the API as it stands (however I can't see a better alternative!).
>
> On 4 Jul 2011, at 09:51, 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
>>>>>
>>>>>
>>>>>
>
>