Issue Details (XML | Word | Printable)

Key: JMS_SPEC-130
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Nigel Deakin
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
jms-spec

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

Created: 18/Jun/13 03:57 PM   Updated: 18/Jun/13 04:20 PM
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Related
 

Tags: jms21-forreview-major
Participants: Nigel Deakin


 Description  « Hide

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.



Nigel Deakin made changes - 18/Jun/13 03:58 PM
Field Original Value New Value
Tags jms21-forreview-major
Nigel Deakin made changes - 18/Jun/13 04:16 PM
Link This issue is related to JMS_SPEC-129 [ JMS_SPEC-129 ]
Nigel Deakin made changes - 18/Jun/13 04:20 PM
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.