Skip to main content

[javaee-spec users] [jsr342-experts] Re: Re: Re: transactional interceptors

  • From: Reza Rahman <reza_rahman@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: Re: Re: transactional interceptors
  • Date: Wed, 21 Dec 2011 13:15:52 -0500
  • List-id: <jsr342-experts.javaee-spec.java.net>

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/@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






[javaee-spec users] [jsr342-experts] transactional interceptors

Linda DeMichiel 12/20/2011

[javaee-spec users] [jsr342-experts] Re: transactional interceptors

Reza Rahman 12/21/2011

[javaee-spec users] [jsr342-experts] Re: Re: transactional interceptors

Linda DeMichiel 12/21/2011

Message not available

[javaee-spec users] [jsr342-experts] Re: Re: Re: transactional interceptors

Reza Rahman 12/21/2011

[javaee-spec users] Re: [jsr342-experts] Re: transactional interceptors

Pete Muir 12/23/2011
 
 
Close
loading
Please Confirm
Close