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

From: Reza Rahman <>
Date: Wed, 21 Dec 2011 12:25:14 -0500

It's really great to finally see this come through -- two thumbs up :-)!
I hope that this is just the tip of the iceberg in terms of aligning
valuable container services with the managed bean model...

As to your questions, I think the propagation type should be binding
since it is an intrinsic part of @Transactional. When we did this in
Resin, we essentially executed all "system level interceptors" before
all "user defined interceptors". I imagine we need to do something
similar here.

I do think there are other design decisions to think through that we
came across for Resin:
* Should the interceptor be restricted to certain component types (the
answer for us was "no").
* How do we make sure container managed resources very likely to be used
in plain transactional components (such as JPA entity managers, data
sources and JMS resources) are used in a thread-safe manner (the answer
for us was transactional cache/proxies and
* How does the component life-cycle interplay with transactions (in our
case we decided these were orthogonal concerns).
* Do we need to support local JDBC transactions or just JTA (in our case
we decided to stick with JTA).

Also, not to nitpick, but I think PropagationType might be a more
descriptive/appropriate name than TxType for REQUIRED, REQUIRES_NEW, etc?

Lastly, are there plans to update the JTA spec? If so, I have a few
ideas that might be worth considering? Some of it is outlined here: It basically
pertains to modernizing/buttoning-up the JTA spec a bit.

On 12/20/2011 6:16 PM, Linda DeMichiel wrote:
> As part of better aligning managed bean technology across the
> platform, one of the improvements we've targeted for this release
> is the extension of "container-managed" transactions (CMT) beyond EJB.
> CMT is one of the original ease-of-use facilities of EJB. It entails
> the specification of declarative transaction attributes on enterprise
> bean classes or methods. The container intercepts the corresponding
> method calls and interposes the necessary operations to initiate,
> suspend, or complete JTA transactions.
> In order to allow CMT-like functionality to be more broadly supported,
> we propose to standardize on CDI interceptors to implement transactional
> interpositioning on managed bean methods.
> More concretely, the proposal is the following:
> We propose to standardize on an annotation + element values that
> capture the semantics of the current EJB transaction attributes
> (Required, RequiresNew, Mandatory, Supports, NotSupported, Never).
> This annotation and standardized values would be added to the
> javax.transaction package.
> For example, this might look as follows:
> @Inherited
> @InterceptorBinding
> @Target({TYPE,METHOD})
> @Retention(RUNTIME)
> public @interface Transactional {
> TxType value() default TxType.REQUIRED
> }
> public enum TxType {
> }
> The JTA specification would also define the semantics of the
> corresponding interceptor classes. (Note that the classes themselves
> would not be defined, but left to the JTA implementation.)
> These transactional interceptors would then be applied using the
> standard CDI protocols. They would be applicable to all CDI managed
> beans as well as to classes defined as managed beans by the Java EE
> specification such as servlets, JAX-RS resource classes, and JAX-WS
> service endpoints.
> There are a few open issues here that require consideration, e.g.:
> (1) Whether the "value" attribute of the "Transactional" annotation
> should be binding or @NonBinding. Note that this decision affects
> the number of interceptor classes that would need to be defined.
> (2) Interceptor ordering. This is currently an open topic in the CDI
> expert group. Presumably it would be desirable for "system-level"
> interceptors such as transactional interceptors to be executed before
> user-defined "application-level" interceptors, but there needs to be
> a mechanism to allow such orderings to be specified in a flexible way.
> We would like to get feedback on this proposed approach and the
> related issues from the group. Other specleads should feel free to
> forward this message to their expert groups for further discussion, if
> relevant.
> thanks,
> -Linda
> -----
> No virus found in this message.
> Checked by AVG -
> Version: 2012.0.1890 / Virus Database: 2109/4694 - Release Date: 12/21/11