users@jms-spec.java.net

[jms-spec users] [jsr343-experts] (JMS_SPEC-69) Clarify that QueueRequestor and TopicRequestor only work in a non-transacted session with auto or dups-ok ack

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Mon, 30 Jan 2012 12:14:51 +0000

I have logged the following issue:
Clarify that QueueRequestor and TopicRequestor only work in a non-transacted session
http://java.net/jira/browse/JMS_SPEC-69

This is all pretty trivial so I don't particularly need anyone to review this unless they particularly want to. (It was
raised by the CTS team).

(I'm going to defer this until after the Early Draft)

The javadocs for QueueRequestor and TopicRequestor state that "This implementation assumes the session parameter to be
non-transacted, with a delivery mode of either AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE".

* There is no mention of this in the spec in section 5.10 "QueueRequestor" or 6.14 "TopicRequestor". This should be
clarified.

* In addition, the class comment should also mention this restriction.

There is no reason why a user could not implement a modified version of this class which uses client-ack. However there
is a more general issue regarding the use of transactions with request-reply messaging:

* It would also be worth mentioning the general point that if an application implements request/reply messaging, the
request message must not be sent within the same transaction as the reply is received.

* It would also be worth mentioning that this means that a QueueRequestor and TopicRequestor cannot be used in a Java EE
web or EJB container when there is an active JTA transaction.

* The following text copied from the EJB spec might be worth including in a modified form somewhere in the spec (in the
2.0 Early Draft it has been added to Section 12.3 "Behaviour of JMS sessions in the Java EE web or EJB container" but
since this isn't specific to Java EE it should be moved somewhere more appropriate)

{quote}
The Bean Provider should not make use of the JMS request/reply paradigm (sending of a JMS message, followed by the
synchronous receipt of a reply to that message) within a single transaction. Because a JMS message is typically not
delivered to its final destination until the transaction commits, the receipt of the reply within the same transaction
will not take place.
{quote}