[cdi-dev] Async events. We need ideas to improve CDI-499
Antoine Sabot-Durand
antoine at sabot-durand.net
Tue Feb 10 05:33:08 EST 2015
Guys,
We surely have more to think about these subject. What I propose is to write today a document exposing all the question regarding async events and we’ll try to give answer and agreed at the next meeting tomorrow (you'll be able prepare you answer and even contribute them to the doc tonight or write question I would have missed) and the week after if necessary. I’ll wrote this doc starting from CDI-499 and remarks in this thread. The idea is to have something simple for users yet with minimal or no limitation for advanced users (framework developer, side).
But remember this will work if EVERYONE participate to the meeting or to the discussion. We don’t have an infinite time to produce CDI 2.0. I agree that it is very important to do it well, but returning to points already discussed (even with the best reason) impact our features list and is a lost of time for everyone. So try to keep the rhythm or raise hand when a subject is important to you and you don’t have time follow : we can switch to another topic waiting for your feedback.
On my side, I’ll try to give your more visibility on meeting agenda and will post link to the minutes here to avoid this “going-back" effect.
regards,
Antoine
> Le 10 févr. 2015 à 10:53, Mark Struberg <struberg at yahoo.de> a écrit :
>
> purely technically: How do you manage to not spawn a new thread if you don't like to wait for the task to complete?
>
> Wonder how that would work...
>
> LieGrue,
> strub
>
>
>
>
>> On Tuesday, 10 February 2015, 10:50, Jozef Hartinger <jharting at redhat.com> wrote:
>>> Async is not about a parallel thread. It is about fire() not waiting
>> until an observer finishes. Transactional observers are async already.
>> No need to make things more complicated by involving a "parallel
>> thread".
>>
>>
>> On 02/10/2015 10:42 AM, Mark Struberg wrote:
>>> No they are not async in the sense that they get executed in a parallel
>> thread. That simply won't work. Think about
>> TransactionPhase.BEFORE_COMPLETION.
>>> There is a huge difference between 'it will get called on the same
>> thread but I have no control _when_' and 'it will get called on a
>> totally new thread'-
>>>
>>> For the TransactionPhase it is the first case imo.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>>
>>>> On Tuesday, 10 February 2015, 10:30, Jozef Hartinger
>> <jharting at redhat.com> wrote:
>>>>> T ransactional observers are by definition async so they should
>> behave
>>>> the same no matter if fired with fire() or fireAsync().
>>>>
>>>>
>>>> On 02/10/2015 09:13 AM, Mark Struberg wrote:
>>>>> Oh one more thing I found which is most probably broken or
>> totally changes
>>>> the behaviour
>>>>> 8.) All observers with transactionPhase != IN_PROGRESS
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Tuesday, 10 February 2015, 8:58, Mark Struberg
>>>> <struberg at yahoo.de> wrote:
>>>>>>> Hi José!
>>>>>> Backward compatibility is perfectly fine with both
>> approaches. People
>>>> can use
>>>>>> BeanManager#fire() instead of the newly proposed
>>>> BeanManager#fireAsync().
>>>>>>
>>>>>> My point is that many people will simply not be able to use
>> fireAsync()
>>>> because
>>>>>> as a framework developer you really need to code defensive.
>> Without an
>>>> explicit
>>>>>> opt-in on observer side fireAsync() can basically only be
>> used in
>>>> situations
>>>>>> where you _exactly_ know all your observers...
>>>>>>
>>>>>> An No @Async annotation would also be nice as it could not
>> only be
>>>> used at
>>>>>> @Observes but also for @Event
>>>>>>
>>>>>> @Inject
>>>>>> @Async
>>>>>>
>>>>>> @Event
>>>>>>
>>>>>> private Event<UserLoggedIn> userLoggedInEventSource;
>>>>>>
>>>>>>
>>>>>> The benefit of an own @Async annotation over extending e.g.
>> the @Event
>>>>>> annotation is that it would be perfectly backward compatible.
>> This code
>>>> would
>>>>>> also run on CDI-1.0 .. 1.2 containers (as all annotations
>> which are not
>>>>>> available on the classpath will simply be ignored by the JVM.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider
>> licenses the
>>>> code under the Apache License, Version 2
>>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>> provided
>>>> on this list, the provider waives all patent and other intellectual
>> property
>>>> rights inherent in such information.
>>>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/cdi-dev/attachments/20150210/b9d8a2c2/attachment.bin
More information about the cdi-dev
mailing list