[cdi-dev] Fwd: [javaee-spec users] [jsr342-experts] transactional interceptors

[Pete Muir]

All, FYI

Please review this carefully, as this is one of the most requested features for CDI - ability to use transactions in CDI managed beans.

Begin forwarded message:

> 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
> 
> 
> 
>