jms-spec
  1. jms-spec
  2. JMS_SPEC-130

Allow a JMSContext or Session to opt out of a Java EE transaction

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      The JMS 2.0 specification, section 12.3 "Behaviour of JMS sessions in the Java EE web or EJB container" states that if a Session or JMSContext is created when there is an active JTA transaction in progress then any session parameters are ignored and the Session or JMSContext will participate in the JTA transaction and will be committed or rolled back when the JTA transaction is committed or rolled back.

      The specification doesn't appear to offer any choice as to whether the Session or JMSContext participates in the JTA transaction.

      Issue: Should it be possible for the Session or JMSContext to "opt out" of the transaction in some way?

      Here are some circumstances in which the JTA transaction might be ignored:

      • If the JMS provider doesn't support XA. The specification is not clear on whether a JMS provider is required to support XA in the Java EE web and EJB containers. In JMS 2.0, section 6.2.8 "Distributed transactions" states that "JMS does not require that a provider support distributed transactions". However this wording dates from JMS 1.1 and it is possible that this statement is intended to apply only to standalone JMS providers which don't support Java EE. This should be clarified.
      • If the connection factory has been configured to not use a JTA transaction. Here are some possible ways in which a conneciton factory might be configured to not use JTA:
        • Using a JMSConnectionFactoryDefinition annotation with the transactional attribute set to false. (The javadocs says that this attribute may be "Set to false if connections should not participate in transactions.
        • Using a connection factory which has been configured in a provider-specific manner to not use JTA transaction.
        • By some standard mechanism, not yet defined, either on the connection factory or the deployment descriptor (see below)
        • By some new parameter to createSession or createContext. (We can't use the existing parameters since these must be ignored in accordance with the EJB 3.1 specification)

      If the Session or JMSContext is allowed to opt out of the JTA transaction, then we could define that it behave the same way as a Session or JMSContext that is created when there is no JTA transaction (i.e. only AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE are allowed).

      However another possibility is to further extend the specification to allow client-acknowledgement or a local transactions to be used. I think that can be discussed as a separate issue and I have created JMS_SPEC-131 to cover it.

        Issue Links

          Activity

          Nigel Deakin created issue -
          Nigel Deakin made changes -
          Field Original Value New Value
          Tags jms21-forreview-major
          Nigel Deakin made changes -
          Link This issue is related to JMS_SPEC-129 [ JMS_SPEC-129 ]
          Nigel Deakin made changes -
          Description The JMS 2.0 specification, section 12.3 "Behaviour of JMS sessions in the Java EE web or EJB container" states that if a {{Session}} or {{JMSContext}} is created when there is an active JTA transaction in progress then any session parameters are ignored and the {{Session}} or {{JMSContext}} will participate in the JTA transaction and will be committed or rolled back when the JTA transaction is committed or rolled back.

          The specification doesn't appear to offer any choice as to whether the {{Session}} or {{JMSContext}} participates in the JTA transaction.

          *Issue:* Should it be possible for the Session or JMSContext to "opt out" of the transaction in some way?

          Here are some circumstances in which the JTA transaction might be ignored:

          * _If the JMS provider doesn't support XA._ The specification is not clear on whether a JMS provider is required to support XA in the Java EE web and EJB containers. In JMS 2.0, section 6.2.8 "Distributed transactions" states that "JMS does not require that a provider support distributed transactions". However this wording dates from JMS 1.1 and it is possible that this statement is intended to apply only to standalone JMS providers which don't support Java EE. This should be clarified.

          * _If the connection factory has been configured to not use a JTA transaction_. Here are some possible ways in which a conneciton factory might be configured to not use JTA:
          ** Using a {{JMSConnectionFactoryDefinition}} annotation with the {{transactional}} attribute set to false. (The javadocs says that this attribute may be "Set to false if connections should not participate in transactions.
          ** Using a connection factory which has been configured in a provider-specific manner to not use JTA transaction.
          ** By some standard mechanism, not yet defined, either on the connection factory or the deployment descriptor (see below)
          ** By some new parameter to {{createSession}} or {{createContext}}. (We can't use the existing parameters since these must be ignored in accordance with the EJB 3.1 specification)

          If the {{Session}} or {{JMSContext}} is allowed to opt out of the JTA transaction, does it simply behave the same way as a {{Session}} or {{JMSContext}} that is created when there is no JTA transaction (i.e. only {{AUTO_ACKNOWLEDGE}} and {{DUPS_OK_ACKNOWLEDGE}} are allowed), or should the specificaiton be further extended to allow client-acknowledgement or a local transactions to be used?

          The JMS 2.0 specification, section 12.3 "Behaviour of JMS sessions in the Java EE web or EJB container" states that if a {{Session}} or {{JMSContext}} is created when there is an active JTA transaction in progress then any session parameters are ignored and the {{Session}} or {{JMSContext}} will participate in the JTA transaction and will be committed or rolled back when the JTA transaction is committed or rolled back.

          The specification doesn't appear to offer any choice as to whether the {{Session}} or {{JMSContext}} participates in the JTA transaction.

          *Issue:* Should it be possible for the Session or JMSContext to "opt out" of the transaction in some way?

          Here are some circumstances in which the JTA transaction might be ignored:

          * _If the JMS provider doesn't support XA._ The specification is not clear on whether a JMS provider is required to support XA in the Java EE web and EJB containers. In JMS 2.0, section 6.2.8 "Distributed transactions" states that "JMS does not require that a provider support distributed transactions". However this wording dates from JMS 1.1 and it is possible that this statement is intended to apply only to standalone JMS providers which don't support Java EE. This should be clarified.

          * _If the connection factory has been configured to not use a JTA transaction_. Here are some possible ways in which a conneciton factory might be configured to not use JTA:
          ** Using a {{JMSConnectionFactoryDefinition}} annotation with the {{transactional}} attribute set to false. (The javadocs says that this attribute may be "Set to false if connections should not participate in transactions.
          ** Using a connection factory which has been configured in a provider-specific manner to not use JTA transaction.
          ** By some standard mechanism, not yet defined, either on the connection factory or the deployment descriptor (see below)
          ** By some new parameter to {{createSession}} or {{createContext}}. (We can't use the existing parameters since these must be ignored in accordance with the EJB 3.1 specification)

          If the {{Session}} or {{JMSContext}} is allowed to opt out of the JTA transaction, then we could define that it behave the same way as a {{Session}} or {{JMSContext}} that is created when there is no JTA transaction (i.e. only {{AUTO_ACKNOWLEDGE}} and {{DUPS_OK_ACKNOWLEDGE}} are allowed).

          However another possibility is to further extend the specification to allow client-acknowledgement or a local transactions to be used. I think that can be discussed as a separate issue and I have created JMS_SPEC-131 to cover it.

            People

            • Assignee:
              Unassigned
              Reporter:
              Nigel Deakin
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: