1. jta-spec
  2. JTA_SPEC-5

support for container-managed transactions independent of (decoupled from) EJB


    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:


      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:



      public @interface Transactional {
      TxType value() default TxType.REQUIRED

      public enum TxType {

      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

      The proposal for exception handling is as follows:

      By default, "application exceptions" (i.e., checked exceptions /
      instances of Exception and its subclasses other than RuntimeException)
      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 via the Transactional
      annotation. More specifically, we propose adding to the
      Transactional annotation an element to specify additional
      exceptions that result in the interceptor marking the
      transaction for rollback and an element to specify exceptions
      that do not cause the interceptor to mark the transaction for rollback.

      For example:


      {TYPE, METHOD}

      public @interface Transactional {
      TxType value() default TxType.REQUIRED;
      Class[] rollbackOn() default {};
      Class[] dontRollbackOn() default {};

      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.





      will override behavior for application exceptions, causing the
      transaction to be marked for rollback for all application exceptions.




      will prevent transactions from being marked for rollback by the
      interceptor when an IllegalStateException or any of its subclasses
      reaches the interceptor.






      will cause the transaction to be marked for rollback for all
      runtime exceptions and all SQLException types except for SQLWarning.

      Note that we are assuming that there is no special, built-in knowledge
      about EJB application exceptions (i.e., runtime exceptions annotated
      with @ApplicationException). As far as the interceptor is concerned,
      these would be treated just as any other runtime exceptions unless
      otherwise specified.



          • Assignee:
          • Votes:
            0 Vote for this issue
            1 Start watching this issue


            • Created: