Reza,
Thanks for the feedback. More below.....
On 12/21/2011 9:25 AM, 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.
> 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.
>
> 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").
> * 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).
> * Do we need to support local JDBC transactions or just JTA (in our case we decided to stick with JTA).
>
> Also, not to nitpick, but I think PropagationType might be a more descriptive/appropriate name than TxType for REQUIRED,
> REQUIRES_NEW, etc?
>
Suggestions for improved naming are always welcome :-)
> 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.
>
Yes. We plan to do a Maintenance Release of the JTA spec. We're planning to set up a java.net
project for that work. Stay tuned -- I'll keep you all posted once this is live.
-Linda
> 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
>>
>>
>
>