users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: transactional interceptors vs. EJB

From: Yoon Kyung Koo <kyungkoo_yoon_at_tmax.co.kr>
Date: Wed, 20 Mar 2013 11:00:24 +0900

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.