Hi Jeremy,
I think the spec should say that they are not supported, and will fail
deployment, but that this restriction may be removed in a future release.
-marina
On 3/18/13 9:31 AM, Jeremy Bauer wrote:
> Hi Marina,
>
> This does seem like the a good approach given all the subtleties.
> Question - what will be added to the spec make it illegal? For
> example, will the server be required to fail to deploy the module if
> it detects the use of @Transactional on a CMT EJB?
>
> -Jeremy
>
>
>
> From: Marina Vatkina <marina.vatkina_at_oracle.com>
> To: jsr345-experts_at_ejb-spec.java.net, users_at_interceptors-spec.java.net,
> Date: 03/15/2013 07:40 PM
> Subject: [jsr345-experts] IMPORTANT: Fwd: [jsr342-experts]
> transactional interceptors vs. EJB
> ------------------------------------------------------------------------
>
>
>
> 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>_
> <mailto:bill.shannon_at_oracle.com>
> *Reply-To: *
> _jsr342-experts_at_javaee-spec.java.net_
> <mailto:jsr342-experts_at_javaee-spec.java.net>
> *To: *
> _jsr342-experts_at_javaee-spec.java.net_
> <mailto: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.
>
>
>