[cdi-dev] transactional interceptors

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