I think it works as designed. The CDI spec states that the request context is active during remote method invocation of any EJB. The problem with transactional observers is that these may be notified asynchronously, i.e. outside the remote EJB invocation and so I think it makes sense that you get a different request context. Although I agree that it's not clearly defined.
If we look at the reproducer, the business method CDITestBean.insert() does not define TransactionAttribute and in CMT (default if no transaction management is specified) this is interpreted as REQUIRED, see also EJB 3.2 spec, "8.3.7 Specification of the Transaction Attributes for a Bean’s Methods":
By default, if a TransactionAttribute annotation is not specified for a method of an enterprise bean with container-managed transaction demarcation, the value of the transaction attribute for the method is defined to be REQUIRED.
So when CDITestBean.insert() is invoked a new transaction is started and after the method completes the transaction completes successfully and the transactional observer is notified.
The CDI spec states, "10.5.1. Observer method invocation context":
-
...
-
Otherwise, if the observer method is any other kind of transactional observer method, it is called in an unspecified transaction context, but with the same client security context and lifecycle contexts as the transaction that just completed.
-
...
But I'm not really sure what this bullet is about. As the relation between transaction and lifecycle contexts is not defined.
|