-
Bug
-
Resolution: Done
-
Blocker
-
None
-
Migration, Compatibility/Configuration, User Experience
-
-
Regression
-
Asynchronous Invocations are not supposed to be part of the callers transaction because there is no guarantee that the async call is executed in parallel or after the caller already ended.
This will cause warnings and exceptions if the asynchronous call is trying to use the transaction while the container is commiting or rolling back the transaction.
It will break compatibility when migrating from earlier version (<=7.0).
According to the EJB specification
~~~quote
4.5.3 Transactions
The client’s transaction context does not propagate with an asynchronous method invocation. From the
Bean Provider’s point of view, there is never a transaction context flowing in from the client. This
means, for example, that the semantics of the REQUIRED transaction attribute on an asynchronous
method are exactly the same as REQUIRES_NEW.
~~~
- clones
-
JBEAP-18371 [GSS](7.3.0) Calling Asynchronous EJB will use the propagated caller transaction which is not according to the specification
- Closed
- is incorporated by
-
JBEAP-18369 [GSS](7.2.z) Calling Asynchronous EJB will use the propagated caller transaction which is not according to the specification
- Closed
- relates to
-
WFLY-12950 [EAT] Multiversion Asynchronous EJB test
- Resolved