On 12/07/2012 19:06, Nigel Deakin wrote:
> On 27/06/2012 11:04, Nigel Deakin wrote:
>> I sent an email on 25th May which described various clarifications in the definition of this new feature and which
>> proposed a number of restrictions. I have received no comments from the Expert Group. However I have received a lot
>> of feedback from within Oracle (where's we're thinking of how to implement it in the RI and other products) and am
>> now proposing the following modified text. Please give your comments by the end of *Friday 6th July.*
>>
> I haven't had much feedback on this, with the only doubts coming from Chris Barrow who wondered whether these
> proposals were "babysitting" the developer too much, which was followed by a comment from Rüdiger who thought they
> weren't. Given the fact that there is clear support for this feature as a whole I think we should proceed with these
> detailed changes. If you object say now. I'll draft the actual spec changes shortly.
>
I have now made the necessary changes to the draft spec, javadoc and CompletionListener API.
There's a summary of the changes in the JIRA issue:
http://java.net/jira/browse/JMS_SPEC-43#action_343155
I have added the extensive clarifications I proposed to a major new section on asynchronous send. I've added a slightly
condensed version to the javadoc of each method on JMSContext and MessageProducer which performs an asynchronous send.
Remember you can browse the javadocs at
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html
As always, whilst drafting the detailed words I felt it necessary to make a few small changes:
I modified the section which stated "An asynchronous send is not permitted in a Java EE EJB or web container" to state
that "If the application component violates this restriction this method may throw a JMSException (if permitted by the
method signature) or JMSRuntimeException". This is consistent (including the use of "may") with the various other
methods which aren't allowed in a Java EE EJB or web container.
You will remember that we have been debating whether we need to restrict access to a message after send() has returned,
and whether such restrictions are enforced by the JMS provider. This is what I proposed in my previous email:
* (A) After the send method has returned, the application must not attempt to read the headers, properties or payload
of the Message object until the CompletionListener's onCompletion or onException method has been called. This is
because the JMS provider may be modifying the Message object in another thread during this time. The JMS provider
must throw a JMSException or JMSRuntimeException (depending on the method signature) if the application attempts to
read the Message in such a case.
* (B) After the send method has returned the application must not attempt to change the state of the message or send
the message a second time, either using an asynchronous or normal send operation. This applies even after the
CompletionListener's onCompletion or onException method has been called. Even though it would be theoretically
possible to allow the Message object to be re-used after the CompletionListener's onCompletion or onException method
has been called, such use is not allowed to avoid an application being created which succeeds when callbacks were
fast and which fails when callbacks are slow
I have now realised that it is difficult to enforce these restrictions if the message being sent is implemented by a
different JMS provider. I have therefore made it optional to enforce the restriction in (A), and dropped the restriction
in (B), because it makes less sense if (A) is optional.
The restriction is now described as follows:
* After the send method has returned, the application must not attempt to read the headers, properties or payload of
the Message object until the CompletionListener's onCompletion or onException method has been called. This is
because the JMS provider may be modifying the Message object in another thread during this time. A JMSException may
be thrown if the application attempts to access or modify the Message object after the send method has returned and
before the CompletionListener has been invoked.
So there's no explicit restriction on sending a message a second time, so long as they wait until the previous send was
completed. If they send a message before the previous send is completed they may get an exception but this is not
obligatory.
Nigel