Hi, Bill.
We think adding restriction is good enough.
Regards,
Yoon Kyung Koo
--
--------------------
Software Innovation Driver
Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
PGP http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
2013. 3. 16., ¿ÀÀü 9:26, Bill Shannon <bill.shannon_at_oracle.com> ÀÛ¼º:
>
> 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.