jsr342-experts@javaee-spec.java.net

[jsr342-experts] transactional interceptors

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Tue, 20 Dec 2011 15:16:38 -0800

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 {
        REQUIRED,
        REQUIRES_NEW,
        MANDATORY,
        SUPPORTS,
        NOT_SUPPORTED,
        NEVER
}


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