From: Pete Muir <pmuir(a)bleepbleep.org.uk&gt; To: cdi-dev(a)lists.jboss.org Cc: Sent: Wednesday, December 21, 2011 12:51 PM Subject: [cdi-dev] Fwd: [javaee-spec users] [jsr342-experts] transactional interceptors 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(a)oracle.com&gt; > Subject: [javaee-spec users] [jsr342-experts] transactional interceptors > Date: 20 December 2011 23:16:38 GMT > To: jsr342-experts(a)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 > > > > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

On 21/12/2011, at 11:19 PM, Mark Struberg wrote: > a.) how will the support for multiple databases work? That is covered by the JTA spec. If you are enrolling multiple datasources they should be XA datasources, and 2 phase commit will be used (i.e. same as ejb's, and all other EE transactional resources). > b.) what about the @TransactionScoped > This should not be affected. The scope should behave the same wether the transaction is controlled by the container or by the end user, although should make sure that the behaviour between EJB's and CDI components is the same. Stuart > LieGrue, > strub > > > > ----- Original Message ----- >> From: Pete Muir <pmuir(a)bleepbleep.org.uk&gt; >> To: cdi-dev(a)lists.jboss.org >> Cc: >> Sent: Wednesday, December 21, 2011 12:51 PM >> Subject: [cdi-dev] Fwd: [javaee-spec users] [jsr342-experts] transactional interceptors >> >> 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(a)oracle.com&gt; >>> Subject: [javaee-spec users] [jsr342-experts] transactional interceptors >>> Date: 20 December 2011 23:16:38 GMT >>> To: jsr342-experts(a)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 >>> >>> >>> >>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev