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
>>>>>>
>>>>>>
>>