Please read this email sent to the Java EE EG.
This proposal reduces the complexity of mixing transactional
interceptors with CMT rules in the EJB spec, by restricting their use in
the EJBs.
I will also remove the current (and quite confusing) statements from the
Interceptors spec that transaction context of interceptors may be
changed by transactional interceptors in the invocation chain.
Best,
-marina
-------- Original Message --------
Subject: [javaee-spec users] [jsr342-experts] transactional
interceptors vs. EJB
Date: Fri, 15 Mar 2013 17:26:54 -0700
From: Bill Shannon <bill.shannon_at_oracle.com>
Reply-To: jsr342-experts_at_javaee-spec.java.net
To: jsr342-experts_at_javaee-spec.java.net
The new @Transactional annotation in JTA is implemented as an
interceptor. We didn't have to add any special support for
transactional interceptors, we just used the general interceptor
support in a specific way to provide this new capability.
That's a good thing. Fewer special cases, more generality.
The EJB spec first introduced the idea of interceptors, and we
want interceptors of all kinds to continue to be usable with EJBs.
Again, a good thing. General capabilities combined orthogonally.
EJB already supports Container Managed Transactions, but there have
been concerns about how CMT interacts with the new transactional
interceptors that generalize this capability for all beans. We've
specified how these capabilities work so that it makes their
interaction well-defined, although it can be complex to understand
exactly what happens in all cases. In many cases, the interaction is
complex enough that most people will be better off never trying to use
the new transactional interceptors with EJBs.
Still, we've resisted making this illegal.
After introducing new general capabilities that remove special cases,
we didn't want to add a new special case. We didn't want people to
believe that some kinds of interceptors can't be used with EJBs.
And we didn't want platform implementors to fail to implement
interceptor support for EJBs in a way that would prevent this, and
potentially other, cases from working.
As we've worked through more of the details of transactional
interceptors, especially for lifecycle methods (see my earlier message
to the expert group), we've had a change of heart.
We're now convinced that the interactions between EJB CMT and transactional
interceptors are subtle enough and complex enough that we should just
tell developers to never do this, and add a special case to make this
illegal.
I know some of you will be happy with this result. :-)
For others, remember that we always have the option of removing this
restriction in a future release, if needed.
Lacking any immediate negative feedback, we'll add this special case
restriction to the EJB spec.
Thanks.