Skip to main content

[jms-spec users] [jsr343-experts] Re: (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@...>
  • To: jsr343-experts@...
  • Subject: [jms-spec users] [jsr343-experts] Re: (JMS_SPEC-69) Clarify that QueueRequestor and TopicRequestor only work in a non-transacted session with auto or dups-ok ack
  • Date: Mon, 28 Jan 2013 12:58:37 +0000
  • List-id: <jsr343-experts.jms-spec.java.net>
  • Organization: Oracle Corporation

(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}





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

Nigel Deakin 01/28/2013
 
 
Close
loading
Please Confirm
Close