@Asynchronous doesn't belong in org.eclipse.microprofile.faulttolerance
See original GitHub issueThe notion of an @Asynchronous
method is one that’s existed in Java EE since it was introduced in EJB 3.1. It was arguably a mistake at the time to have put this annotation in the javax.ejb
package, instead of allowing it to have been used with any CDI bean, but the history was that at the time CDI was a under a cloud of controversy and trying to present as small a target as possible, and was therefore trying not to step on EJB’s toes too much.
So the addition of org.eclipse.microprofile.faulttolerance.Asynchronous
which can, as I understand it, be used on any CDI bean is a big improvement from this point of view. Now, if I’m not misunderstanding, we can add asynchronous methods to any CDI bean. Excellent, if true!
However, from what I can tell from a cursory inspection of its documented semantics, @Asynchronous
doesn’t have anything much in the way of semantics that are specific to Fault Tolerance. That makes sense: asynchronicity and fault tolerance are relatively orthogonal concerns, though I can see how there are some semantics that need to be well-defined at their intersection.
Nevertheless, asynchronicity isn’t an aspect of Fault Tolerance, and therefore it doesn’t seem to me that @Asynchronous
belongs in the org.eclipse.microprofile.faulttolerance
package. I’m not sure where it does belong, but … not there.
Hrrrrm, perhaps a better place for it to live would be in org.eclipse.microprofile.concurrent
, since it seems much more closely related to the functionality in that package? I’m not sure.
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (9 by maintainers)
Top GitHub Comments
Thank you @gavinking for your thoughts! Inventing
@Asynchronous
was originally triggered to specify a multithreading mode of bulkhead. As per your comments, since there is no such asynchronous api, we have to introduce it first. This annotation is quite useful. I like what you suggested though. Maybe it is better to be moved under concurrency spec. When the concurrency spec is released, we can interlock more to see whether we can make that move.@Emily-Jiang yep, great. Indeed, I hope the Concurrency spec will define a relationship between
@Asynchronous
andManagedExecutor
s, which would make the connection even clearer.