On 21 Dec 2011, at 17:25, Reza Rahman wrote:
> It's really great to finally see this come through -- two thumbs up :-)! I hope that this is just the tip of the iceberg in terms of aligning valuable container services with the managed bean model...
>
> As to your questions, I think the propagation type should be binding since it is an intrinsic part of @Transactional.
Could you expand on this, as I don't see why it being intrinsic bears on whether it is a binding part of the qualifier or not.
However, I do think making it binding is easier and will perform better. In this case, my design would be to have one interceptor for each type of propagation, which extend some base interceptor. All the logic would be in the base interceptor, with the concrete class just used to identify which propagation type was selected. This then pushes the work of introspecting the propagation type to the CDI container.
> When we did this in Resin, we essentially executed all "system level interceptors" before all "user defined interceptors". I imagine we need to do something similar here.
This is certainly what we want by default. However, we weren't sure whether to force this on people, or allow an extension or app to override it.
>
> I do think there are other design decisions to think through that we came across for Resin:
> * Should the interceptor be restricted to certain component types (the answer for us was "no").
Agreed, it's useful for all sorts of components to be transactional.
> * How do we make sure container managed resources very likely to be used in plain transactional components (such as JPA entity managers, data sources and JMS resources) are used in a thread-safe manner (the answer for us was transactional cache/proxies and @TransactionScoped/_at_ThreadScoped).
> * How does the component life-cycle interplay with transactions (in our case we decided these were orthogonal concerns).
I think we can treat this as a related, but separate issue.
> * Do we need to support local JDBC transactions or just JTA (in our case we decided to stick with JTA).
Agreed.
>
> Also, not to nitpick, but I think PropagationType might be a more descriptive/appropriate name than TxType for REQUIRED, REQUIRES_NEW, etc?
Agreed.
>
> Lastly, are there plans to update the JTA spec? If so, I have a few ideas that might be worth considering? Some of it is outlined here: http://blog.bitronix.be/2011/02/why-we-need-jta-2-0/. It basically pertains to modernizing/buttoning-up the JTA spec a bit.
>
> On 12/20/2011 6:16 PM, Linda DeMichiel wrote:
>>
>> 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
>>
>>
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1890 / Virus Database: 2109/4694 - Release Date: 12/21/11
>>
>>
>
>