Hi Bill,
Not sure how or if the EJB discussion on this topic comes back to the Java
EE EG, but I had raised this question to Jeremy (the IBM rep for EJB):
> ..that we should just tell developers to never do this, and add a
special case to make this
illegal.
How will this detection be communicated to the end user?
The conversation on the EJB EG is here:
http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2013-03/message/58
Maybe you and Marina have regular discussions, so this is not an issue. I
just didn't want to lose track of this discussion. Thanks.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter, Java EE and Java Persistence API (JPA) architect
mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
http://webspherepersistence.blogspot.com/
phone: tl-553-3620 (office), 507-253-3620 (office)
http://openjpa.apache.org/
From: Bill Shannon <bill.shannon_at_oracle.com>
To: jsr342-experts_at_javaee-spec.java.net,
Date: 03/15/2013 07:46 PM
Subject: [jsr342-experts] transactional interceptors vs. EJB
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.