messaging
messaging copied to clipboard
jakartaee
JMS does not adequately define the behaviour of getAcknowledgeMode, getTransacted and getSessionMode in Java EE
JMS does not adequately define the behaviour of Session#getAcknowledgeMode, Session#getTransacted and JMSContext#getSessionMode in the Java EE web or EJB container.
What the spec currently says about these methods
The javadoc for Session#getAcknowledgeMode state that this method
Returns the acknowledgement mode of the session. The acknowledgement mode is set at the time that the session is created. If the session is transacted, the acknowledgement mode is ignored.
The javadoc for Session#getTransacted state that this method
Indicates whether the session is in transacted mode.
The javadoc for JMSContext#getSessionMode states that this method
Returns the session mode of the JMSContext's session. This can be set at the time that the JMSContext is created. Possible values are JMSContext.SESSION_TRANSACTED, JMSContext.AUTO_ACKNOWLEDGE, JMSContext.CLIENT_ACKNOWLEDGE and JMSContext.DUPS_OK_ACKNOWLEDGE
If a session mode was not specified when the JMSContext was created a value of JMSContext.AUTO_ACKNOWLEDGE will be returned.
However this leaves a number of ambiguities in the case where these methods are called in a Java EE web or EJB container.
Why this is ambiguous
The following discussion relates to the case of a Session created using Connection#createSession(boolean transacted, int acknowledgeMode) but the same issues arise for Session objects created using other methods, and for JMSContext objects.
There are two cases we need to consider: (1) When there is JTA transaction in progress and (2) when there is no JTA transaction in progress.
Case 1: when there is an active JTA transaction in progress
What do Session#getAcknowledgeMode and Session#getTransacted return in the case of a Session that was created when there is an active JTA transaction in progress?
The javadoc for Connection#createSession(boolean transacted, int acknowledgeMode) states that "Both arguments transacted and acknowledgeMode are ignored." So there appear to be two possible interpretations of the spec here.
Either (a) Session#getAcknowledgeMode and Session#getTransacted return the values of transacted and acknowledgeMode supplied by the caller when the Session was created,
or (b) these methods return values of transacted and acknowledgeMode which represent the actual behaviour of the session.
Interpretation (a) cannot be correct since this would contradict the requirement that the values supplied by the caller be "ignored". By definition, if these values are ignored then they will not be remembered by the session.
Interpretation (b) cannot be correct since the spec does not define what values of transacted and acknowledgeMode represent the case where the session participates in the JTA transaction.
The spec is quite explicit that whether or not the session participates in the JTA transaction is determined by whether or not there is a JTA transaction in progress, not by the parameters to createSession, so it does not define any values of these parameters which represent the use of a JTA transaction.
One possible way to implement interpretation (b) might be for Session#getAcknowledgeMode to return Session.SESSION_TRANSACTED and Session#getTransacted to return true.
However this would be ambiguous as it would not provide any distinction between a JTA transaction and a local transaction. It would also be inconsistent with the javadoc for the constant SESSION_TRANSACTED which states that getAcknowledgeMode returns this value "if the session is using a local transaction". There is no mention of it being used to represent a JTA transaction.
Case 2: when there is no active JTA transaction in progress
The same question applies in the case where the session is created when there is no JTA transaction in progress. Again, there are two options.
Either (a) Session#getAcknowledgeMode and Session#getTransacted return the values of transacted and acknowledgeMode supplied by the caller when the Session was created,
or (b) these methods return values of transacted and acknowledgeMode which represent the actual behaviour of the session.
We need to reject (a) for the same reason as stated above, which is that Connection#createSession(boolean transacted, int acknowledgeMode) states is required (or permitted, if we accept #155) to "ignore" the specified parameters.
However (b) is less problematical since there is no need to denote that the session is participating in a JTA transaction. So this would be a reasonable option.
Proposed clarification
It is proposed to clarify the behaviour of the JMSContext method getSessionMode and the Session methods getAcknowledgeMode and getTransacted when in a Java EE web or EJB container as follows:
-
If these methods are called in an active JTA transaction then the values returned are undefined.
-
A future version of JMS might define returned values which represented a JTA transaction, but this might require making incompatible changes to existing JMS providers so this would need careful consideration and is best deferred to a later occasion.
-
If these methods are called when there is no active JTA transaction, and the Session or JMSContext was created when there was also no active transaction, then the values returned must reflect the actual behaviour that would be exhibited by the Session or JMSContext if it were used to consume a message when there was no active JTA transaction.
- Issue Imported From: https://github.com/javaee/jms-spec/issues/156
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: Unassigned
@glassfishrobot Commented @nigeldeakin said: Description updated with a new proposal.
@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-156