[cdi-dev] On @Observes for async events

[Romain Manni-Bucau]

2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <antoine at sabot-durand.net>:

>
> Le 18 mars 2015 à 09:42, Romain Manni-Bucau <rmannibucau at gmail.com> a
> écrit :
>
> Hi guys,
>
> think Mark is right and a new API (as fireAsync) would be better for users
> for:
> - understanding
> - compatibility (think to custom extensions using this flag)
>
>
> My point here is to avoid making CDI the EJB next by introducing @Async or
> @Asynchronous annotation in the spec. This kind of annotation should be
> shared by other specs and would have a better fit in concurrency utilities
> or commons annotations spec.
>
>
+1


> that said if we have @Async methods I think async observers are really
> useless, isn't it?
>
>
> @Async is rather useless IMO when you see how easy it is do async
> operation with Java 8. On the other hand Async observers are a at a higher
> level since they are called thru the Container and that the fire point must
> know what’s going on at the other side.
>
>
don't get it, observer can use j8 then to do its stuff asynchronously so
maybe the feature if finally useless assuming you run on j8.

That said saying a method is async is still more elegant than firing it in
a pool you don't control.


>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com/> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com/>
>
> 2015-03-18 9:30 GMT+01:00 Arne Limburg <arne.limburg at openknowledge.de>:
>
>> Hi Antoine,
>>
>> The third bullet point in 10.5.1 of the CDI 1.1 spec states that the
>> observer method must be called in the same transaction context as the
>> event.fire(...) if it is no transactional observer (that is
>> TransactionPhase.IN_PROGRESS).
>> If the default behavior would be async, we would have to move the
>> transaction context to another thread. To my best knowledge this would be
>> the only situation in EE where this is the case.
>>
>> Cheers,
>> Arne
>>
>> Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter
>> <antoine at sabot-durand.net>:
>>
>> >Hi Arne,
>> >
>> >Sorry can you explain why? This value allows observer to be called inside
>> >or outside a transaction. What will be the compatibility issue?
>> >
>> >Antoine
>> >
>> >
>> >> Le 18 mars 2015 à 09:05, Arne Limburg <arne.limburg at openknowledge.de>
>> a
>> >>écrit :
>> >>
>> >> Hi to all,
>> >>
>> >> I think the biggest issue with backward compatibility is, that the
>> >>current
>> >> @Observes annotation by default has TransactionPhase.IN_PROGRESS.
>> >> I think we can¹t deal with this, if the default for observers would be
>> >> async. So I think there is no way to specify async as default without
>> >> loosing backward compatibility.
>> >> Any other thoughts?
>> >>
>> >> Cheers,
>> >> Arne
>> >>
>> >>
>> >> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter
>> >> <antoine at sabot-durand.net>:
>> >>
>> >>> Hi all,
>> >>>
>> >>> Yesterday we had another meeting to try to find a better solution than
>> >>> explicitly activating async event on observer, without no success. I
>> >>> understand that we should go on on this feature so what I suggest is
>> to
>> >>> have a meeting (an hangout) with people that want to try to find a
>> >>>better
>> >>> solution. If we find something we¹ll do a last proposal, and in all
>> >>>case
>> >>> we¹ll adopt the woking solution next week for this point. People
>> >>> interested with this please manifest yourself.
>> >>>
>> >>> If we have to go with opt-in (have to explicitly declare an observer
>> >>> supporting async event) we also have to validate the decision to use a
>> >>> member in @Observes (as it was decided before) or go back on that as
>> >>> mMark keep asking by introducing a new annotation to add on the
>> >>>observer
>> >>> (@Async or something similar). As I said when we discussed this point,
>> >>>I
>> >>> prefer the member in @Observes but we may have overlooked issues
>> linked
>> >>> to backward compatibility.
>> >>> A third solution might be to introduce an @ObserveAsync to declare an
>> >>> asynchronous capable observerŠ
>> >>>
>> >>> I¹m waiting for active feedback from you to find the best solution
>> >>>taking
>> >>> ALL aspects (not only the technicals one) into account.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Antoine
>> >>
>> >
>>
>>
>> _______________________________________________
>> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/f3813ab8/attachment-0001.html