<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>Will the spec discuss an approach for interoperability with EJB? e.g. What happens if a @Transactional CDI beans invokes a session bean (and vice versa). Will the correct transaction demarcation happen? Depending on the implementation this might already
work automatically, but if it doesn't work it would be very confusing to users.</div>
<div><br>
</div>
<div>My other question is if JPA integration will be specified as part of this specification (e.g. @PersistenceContext in CDI beans). This is only semi related, but might be relevant.</div>
<div>Besides these questions I'm very much in favor of this approach.</div>
<div><br>
</div>
<div>Paul Bakker</div>
<div><br>
</div>
<div><br>
</div>
<div><span class="Apple-style-span" style="font-family: Times; ">
<pre>><i> From: Linda DeMichiel <<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">linda.demichiel at oracle.com</a>>
</i>><i> Subject: [javaee-spec users] [jsr342-experts] transactional interceptors
</i>><i> Date: 20 December 2011 23:16:38 GMT
</i>><i> To: <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev">jsr342-experts at javaee-spec.java.net</a>
</i>><i>
</i>><i>
</i>><i> As part of better aligning managed bean technology across the
</i>><i> platform, one of the improvements we've targeted for this release
</i>><i> is the extension of "container-managed" transactions (CMT) beyond EJB.
</i>><i>
</i>><i> CMT is one of the original ease-of-use facilities of EJB. It entails
</i>><i> the specification of declarative transaction attributes on enterprise
</i>><i> bean classes or methods. The container intercepts the corresponding
</i>><i> method calls and interposes the necessary operations to initiate,
</i>><i> suspend, or complete JTA transactions.
</i>><i>
</i>><i> In order to allow CMT-like functionality to be more broadly supported,
</i>><i> we propose to standardize on CDI interceptors to implement transactional
</i>><i> interpositioning on managed bean methods.
</i>><i>
</i>><i>
</i>><i> More concretely, the proposal is the following:
</i>><i>
</i>><i> We propose to standardize on an annotation + element values that
</i>><i> capture the semantics of the current EJB transaction attributes
</i>><i> (Required, RequiresNew, Mandatory, Supports, NotSupported, Never).
</i>><i>
</i>><i> This annotation and standardized values would be added to the
</i>><i> javax.transaction package.
</i>><i>
</i>><i> For example, this might look as follows:
</i>><i>
</i>><i> @Inherited
</i>><i> @InterceptorBinding
</i>><i> @Target({TYPE,METHOD})
</i>><i> @Retention(RUNTIME)
</i>><i> public @interface Transactional {
</i>><i> TxType value() default TxType.REQUIRED
</i>><i> }
</i>><i>
</i>><i> public enum TxType {
</i>><i> REQUIRED,
</i>><i> REQUIRES_NEW,
</i>><i> MANDATORY,
</i>><i> SUPPORTS,
</i>><i> NOT_SUPPORTED,
</i>><i> NEVER
</i>><i> }
</i>><i>
</i>><i>
</i>><i> The JTA specification would also define the semantics of the
</i>><i> corresponding interceptor classes. (Note that the classes themselves
</i>><i> would not be defined, but left to the JTA implementation.)
</i>><i>
</i>><i> These transactional interceptors would then be applied using the
</i>><i> standard CDI protocols. They would be applicable to all CDI managed
</i>><i> beans as well as to classes defined as managed beans by the Java EE
</i>><i> specification such as servlets, JAX-RS resource classes, and JAX-WS
</i>><i> service endpoints.
</i>><i>
</i>><i>
</i>><i> There are a few open issues here that require consideration, e.g.:
</i>><i>
</i>><i> (1) Whether the "value" attribute of the "Transactional" annotation
</i>><i> should be binding or @NonBinding. Note that this decision affects
</i>><i> the number of interceptor classes that would need to be defined.
</i>><i>
</i>><i> (2) Interceptor ordering. This is currently an open topic in the CDI
</i>><i> expert group. Presumably it would be desirable for "system-level"
</i>><i> interceptors such as transactional interceptors to be executed before
</i>><i> user-defined "application-level" interceptors, but there needs to be
</i>><i> a mechanism to allow such orderings to be specified in a flexible way.
</i>><i>
</i>><i>
</i>><i> We would like to get feedback on this proposed approach and the
</i>><i> related issues from the group. Other specleads should feel free to
</i>><i> forward this message to their expert groups for further discussion, if
</i>><i> relevant.
</i>><i>
</i>><i> thanks,
</i>><i>
</i>><i> -Linda
</i>><i> </i></pre>
</span>
<div><br>
</div>
</div>
</body>
</html>