Ian Robinson wrote on 03/19/13 13:04:
> http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2013-03/message/58
>
> "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. :-)"
>
> On this - yes I am.
> We also need to discuss the concrete changes that should be made to the JTA MR
> draft. For example we need to discuss what the text should say instead of:
>
> "When Transactional annotated managed beans are used in conjunction with EJB
> container managed transactions the EJB container transaction rules are applied
> before
> the interceptor chain is called. Thus the Transactional interceptors may
> change the
> transaction context created by the EJB container. It is best practice to avoid
> such use of
> Transactional annotations in conjunction with EJB container managed transactions
> in order to avoid possible confusion.."
>
> On this list, please.
> Bill said, back in January "We preferred not to complicate the deployment
> process by requiring it to detect these cases and force deployment to fail"
> although this is what the post above is now proposing. Are there other
> alternatives on the table?
I described this in the platform expert group:
http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-03/message/23
The current proposal is to define this as illegal (something that applications
MUST NOT do), and say that this SHOULD be detected at deployment time and cause
deployment to fail. "SHOULD" gives the Java EE product some flexibility, while
setting expectations that we don't want applications to do this.
This restriction would be in the EJB spec.
Note that the restriction is against EJBs being annotated with @Transactional.
There's no restriction on EJBs using or calling other beans annotated with
@Transactional.
> As an extension to my #3 below, this latest EJB consideration means we also
> need to look at the text in section 3.7 that says:
> "The javax.transaction.Transactional annotation provides the application
> the ability to declaratively control transaction boundaries on CDI managed
> beans,*as*
> *well as classes defined as managed beans by the Java EE specification*, at
> both the class
> and method level."
>
> I would suggest replacing this with:
> "The javax.transaction.Transactional annotation provides the application
> the ability to declaratively control transaction boundaries on CDI managed
> beans at both the class
> and method level. *This annotation cannot be used by classes defined as
> managed beans by the Java EE specification"*
>
> similar to what I proposed below for @TrasansationScoped.
We don't plan to restrict the use of @Transactional with managed beans, except
for the EJB restriction above. No other managed beans have EJB's Container
Managed Transactions, which is what causes the complexity.
> As noted below, I do not want to say "OK" to this MR of JTA without first
> seeing a proposed-final draft containing agreed concrete resolutions to all
> the various items we've been discussing.
The item above will be resolved in the EJB spec. Paul will have an update with
the other items for this spec soon.