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

[Mark Struberg]

a.) how will the support for multiple databases work?
b.) what about the @TransactionScoped

LieGrue,
strub



----- Original Message -----
> From: Pete Muir <pmuir at bleepbleep.org.uk>
> To: cdi-dev at 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 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
>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>