jsr345-experts@ejb-spec.java.net

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

From: Carlo de Wolf <cdewolf_at_redhat.com>
Date: Mon, 15 Aug 2011 11:45:43 +0200

Yes, right now they use:
http://docs.jboss.org/ejb3/docs/tutorial/1.0.7/html/Asynchronous_Invocations.html

The use cases are similar to the ones we try to solve with the current
async specification.

Carlo

On 07/22/2011 08:11 PM, Marina Vatkina wrote:
> Carlo, et al.,
>
> Is it something that you saw users asking about? If yes, did they
> describe the scenarios they were trying to solve?
>
> thanks,
> -marina
>
> Carlo de Wolf wrote:
>> On 07/22/2011 01:15 AM, Marina Vatkina wrote:
>>> 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...
>> The business case is any client that want to use an existing EJB
>> asynchronously. Now it would entail refactoring the EJB.
>>
>> As for the transaction demarcation, it has always been a client side
>> decision to start or not start a tx (or start a new tx) regardless of
>> synchronicity. The bean developer is not aware whether the EJB runs
>> in the same or a new transaction. (If he wants that he should have
>> specified 'Mandatory'.)
>>
>> Carlo
>>
>> PS. One thing that affects both async models is that it can lead to a
>> deadlock. Suppose SFSB A (TxRequired) calls SFSB B synced and then
>> calls SFSB B async followed by future.get(). Ultimately that is an
>> user concern though.
>>> -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
>>>>>>>>
>>>>>>>>
>>>>
>>