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