Hi Ian,
Definitely good point(s) and there were lengthy discussions on this when first drafting the feature though I'm afraid they were just between Oracle and JBoss/CDI at the time.
Those parties are cc'd and can correct me if I've forgotten or missed anything but the main rationale stemmed from the fact that we are trying to decouple the specs as much as possible in general and as EJB CMT is a special case here the interaction of transactional interceptors with CMT should be mentioned in the EJB spec.
I may send a separate dedicated email on this topic but we do need to also decide what exception is to be thrown when a bean with TxType Never is called from within a transactional context as currently it throws an EJBException. Eg, should we throw InvalidTransactionException?
Thanks,
Paul
On Dec 10, 2012, at 4:30 AM, Ian Robinson wrote:
> I probably haven't thought about this enough yet but....
> "It is best practice to avoid such use of Transactional annotations in conjunction with EJB container managed transactions in order to avoid possible confusion."
>
> Why wouldn't we just want to make ANY such combination illegal? There are some odd combinations and difficult to explain behaviours otherwise
>
> e.g. #1 : @TransactionAttribute(MANDATORY) + @Transactional(NEVER)
>
> e.g. #2 Exception handling - how would I reconcile:
>
> @TransactionAttribute(REQUIRES_NEW) + @Transactional(REQUIRED, dontRollbackOn={IllegalStateException.class})
> In the case of an ISE, the CMT is required to be rolledback but the CDI annotation is in conflict.
>
> e.g #3.
>
> @TransactionAttribute(REQUIRES) + @Transactional(REQUIRES_NEW)
> Assume the EJB throws an ISE.
> According to Table 19 in the EJB spec, "Bean method runs in the context of the caller’s transaction. This case may happen with Required, Mandatory, and Supports attributes."
> But it is now no longer true that an EJB with @TransactionAttribute(REQUIRES) always "runs in the context of the caller’s transaction". In the case of an ISE does the caller receive javax.ejb.EJBTransactionRolledbackException or EJBException?
>
> e.g #4.
> Client has no context. EJB specifies:
> @TransactionAttribute(REQUIRES) + @Transactional(REQUIRES_NEW)
> The text leads me to believe I'd start 2 transactions here. Is that right?
> So what about just:
> @Transactional(REQUIRES_NEW) on a CMT EJB?
> Doesn't that have to be the same as the former case since @TransactionAttribute(REQUIRES) is the default for CMT?
>
> My head aches....
>
> Regards,
> Ian
>
>
>
>
> From: Paul Parkinson <paul.parkinson_at_oracle.com>
> To: users_at_jta-spec.java.net,
> Date: 06/12/2012 22:24
> Subject: [jta-spec users] rough draft of JTA 1.2 section 3.7 Transactional Annotation
>
>
>
> Hi,
>
> Below is a rough first run of the JTA 1.2 section 3.7 Transactional Annotation, http://java.net/jira/browse/JTA_SPEC-5
>
> Thank you for any feedback as we need to close this down in the next couple weeks.
>
> Regards,
> Paul
>
>
> 3.7 Transactional Annotation
>
> The javax.transaction.Transactional annotation provides the application the ability to control transaction boundaries on CDI managed beans, as well as classes defined as managed beans by the Java EE
> specification such as servlets, JAX-RS resource classes, and JAX-WS service endpoints, declaratively. This provides the semantics of EJB transaction attributes in CDI without dependencies such as RMI. This support is implemented via an implementation of a CDI interceptor that conducts the necessary suspending, resuming, etc. [*todo specify the number used for the transactional interceptor, so that others can choose to order their interceptors before or after the transactional interceptor; coordinate with CDI for this]
>
> By default checked exceptions do not result in the transactional interceptor marking the transaction for rollback and instances of RuntimeException and its subclasses do. This default behavior can be overridden by specifying which exceptions result in the interceptor marking the transaction for rollback. The rollbackOn element can be set to indicate which exceptions should cause the interceptor to mark the transaction for rollback. Conversely, the dontRollbackOn element can be set to indicate which exceptions should do not cause the interceptor to mark the transaction for rollback. When a class is specified for either of these elements, the designated behavior applies to subclasses of that class as well. If both elements are specified, dontRollbackOn takes precedence.
>
> The following are some example usages of rollbackOn and dontRollbackOn elements.
>
> - The following will override behavior for application exceptions, causing the transaction to be marked for rollback for all application exceptions.
> @Transactional(rollbackOn={Exception.class})
>
> - The following will prevent transactions from being marked for rollback by the interceptor when an IllegalStateException or any of its subclasses reaches the interceptor.
> @Transactional(dontRollbackOn={IllegalStateException.class})
>
> - The following will cause the transaction to be marked for rollback for all runtime exceptions and all SQLException types except for SQLWarning.
> @Transactional(
> rollbackOn={SQLException.class},
> dontRollbackOn={SQLWarning.class}
> )
>
> EJB application exceptions (i.e., runtime exceptions annotated with @ApplicationException) are treated just as any other runtime exceptions unless otherwise specified.
>
> When Transactional annotated managed beans are used in conjunction with EJB container managed transactions the EJB container behavior is applied before the bean is called. When the bean is called the CDI behavior is applied before calling the bean's methods. It is best practice to avoid such use of Transactional annotations in conjunction with EJB container managed transactions in order to avoid possible confusion.
>
> “Java Transaction API Reference” on page 30 has a full description of this annotation
>
>
> [...]
>
>
> /**
> * Annotation used by applications to control transaction boundaries on CDI managed beans, as well as
> * classes defined as managed beans by the Java EE specification such as servlets, JAX-RS resource classes, and JAX-WS
> * service endpoints, declaratively. This provides the semantics of EJB transaction attributes in CDI without
> * dependencies such as RMI. This support is implemented via an implementation of a CDI interceptor that conducts the
> * necessary suspending, resuming, etc. [*todo specify the number used for the transactional interceptor, so that others
> * can choose to order their interceptors before or after the transactional interceptor; coordinate with CDI for this]
> * [*open issue as to whether the "value" attribute of the "Transactional" annotation should be binding or not]
> *
> * By default checked exceptions do not result in the transactional interceptor marking the transaction for rollback
> * and instances of RuntimeException and its subclasses do. This default behavior can be overridden by specifying
> * which exceptions result in the interceptor marking the transaction for rollback. The rollbackOn element can be set
> * to indicate which exceptions should cause the interceptor to mark the transaction for rollback. Conversely, the
> * dontRollbackOn element can be set to indicate which exceptions should do not cause the interceptor to mark the
> * transaction for rollback. When a class is specified for either of these elements, the designated behavior applies
> * to subclasses of that class as well. If both elements are specified, dontRollbackOn takes precedence.
> *
> * EJB application exceptions (i.e., runtime exceptions annotated with @ApplicationException) are treated just as any
> * other runtime exceptions unless otherwise specified.
> *
> * When Transactional annotated managed beans are used in conjunction with EJB container managed transactions the EJB
> * container behavior is applied before the bean is called. When the bean is called the CDI behavior is applied before
> * calling the bean's methods. It is best practice to avoid such use of Transactional annotations in conjunction with
> * EJB container managed transactions in order to avoid possible confusion.
> *
> *
> * @since JTA1.2
> */
> @Inherited
> @InterceptorBinding
> @Target({ElementType.TYPE, ElementType.METHOD})
> @Retention(value = RetentionPolicy.RUNTIME)
> public @interface Transactional {
> TxType value() default TxType.REQUIRED;
>
> public enum TxType {REQUIRED, REQUIRES_NEW, MANDATORY, SUPPORTS, NOT_SUPPORTED, NEVER}
>
> Class[] rollbackOn() default {};
>
> Class[] dontRollbackOn() default {};
>
> }
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU