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 #131 to cover it.
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:
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 #131 to cover it.
Affected Versions
[2.0]