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)
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.