Skip to main content

[jsr342-experts] Re: transactional interceptors

  • From: Reza Rahman <reza_rahman@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: transactional interceptors
  • 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 @TransactionScoped/@ThreadScoped).
* 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:

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



No virus found in this message.
Checked by AVG -
Version: 2012.0.1890 / Virus Database: 2109/4694 - Release Date: 12/21/11

[jsr342-experts] transactional interceptors

Linda DeMichiel 12/20/2011

[jsr342-experts] Re: transactional interceptors

Reza Rahman 12/21/2011

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

Linda DeMichiel 12/21/2011

Message not available

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

Reza Rahman 12/21/2011
Please Confirm