(What follows is a very small documentation update which can be ignored if you're busy...)
In the course of reviewing the spec document I came across this issue (see bottom of email), which I first emailed you
about exactly a year ago.
I have drafted updated text for section 5.10 "QueueRequestor" as follows.
In writing this, what I really want to say is "these classes are not very useful and we're only keeping them for reasons
of backwards compatibility, especially as they require you to use the deprecated QueueSession/TopicSession objects".
However what follows is a slightly more nuanced wording:
OLD TEXT for QueueRequestor
--------
4.1.6. QueueRequestor
JMS provides a QueueRequestor helper class to simplify making service requests.
The QueueRequestor constructor is given a QueueSession and a destination queue. It creates a TemporaryQueue for the
responses and provides a request method that sends the request message and waits for its reply.
This is a basic request/reply abstraction that should be sufficient for most uses. JMS providers and clients can create
more sophisticated versions.
NEW TEXT for QueueRequestor
--------
4.1.6. QueueRequestor
The legacy domain-specific API for point-to-point messaging provides a QueueRequestor helper class to simplify making
service requests.
The QueueRequestor constructor is given a QueueSession and a destination queue. It creates a TemporaryQueue for the
responses and provides a request method that sends the request message and waits for its reply.
This is a very basic request/reply abstraction which assumes the session is non-transacted with a delivery mode of
either AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE. It is expected that most applications will create less basic
implementations.
There is no equivalent to this class for the classic or simplified APIs. Applications using these APIs are expected to
create their own implementations.
Similar changes apply to Section 6.14 "TopicRequestor"
Nigel
On 30/01/2012 12:14, Nigel Deakin wrote:
> 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}
>
>
>