> From: Linda DeMichiel <linda.demichiel at oracle.com> > Subject: [javaee-spec users] [jsr342-experts] transactional interceptors > Date: 20 December 2011 23:16:38 GMT > To: jsr342-experts at javaee-spec.java.net > > > 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 >