On 12/21/2011 12:52 PM, Paul Parkinson wrote:
> On Dec 21, 2011, at 12:33 PM, Linda DeMichiel wrote:
>
>> 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 :-)
> I was going to say the same but suggest "TransactionAttribute" since that is what they are after all (i.e. we aren't inventing something new in this respect so we may as well keep the existing term).
Personally, I'd prefer a clean break from the past:-). I think
@Transactional is more intuitive, concise and semantically correct. If
you look at Spring, Guice, Seam, CODI, etc they all call their
declarative transaction aspect @Transactional.
>>> 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
>>>>
>>>>
>>>
>
>
> -----
> 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
>
>
>