Skip to main content

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

  • From: Yoon Kyung Koo <kyungkoo_yoon@...>
  • To: jsr342-experts@...
  • Cc: "<chanpyo_hong@...>" <chanpyo_hong@...>, "was2@..." <was2@...>
  • Subject: [javaee-spec users] [jsr342-experts] Re: transactional interceptors vs. EJB
  • Date: Wed, 20 Mar 2013 11:00:24 +0900
  • List-id: <jsr342-experts.javaee-spec.java.net>

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@...> 작성:


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.



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

Bill Shannon 03/16/2013

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

Kevin Sutter 03/18/2013

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

Bill Shannon 03/18/2013

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

Kevin Sutter 03/19/2013

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

Yoon Kyung Koo 03/20/2013
 
 
Close
loading
Please Confirm
Close