On 09/10/2009 05:35 PM, Alan Conway wrote:
Acknowledge acks all messages received by the session to date so its
clearly a session operation.
Reject is an operation on a specific message. It is implemented as an
update to the session state, but from the users perspective you reject a
message. Moreover its only legal to reject a message using the session
that it arrived on.
Given a choice between:
message.getSession().reject(message)
message.reject()
the latter seems simpler, more intuitive and less error prone. Why
complicate the API because of the way the implementation works?
I certainly don't like the former! Most of my dislike for the latter
came from the need to hold a session reference on the message, just to
handle reject (though I concede that does make enforcing the rule on the
session to use easy), so a Message::getSession() would be something I'd
avoid.
FWIW, I envisaged the usage more as:
Message message = session.fetch();
//look at it
session.reject(message);
Of course the message could also be fetched from a specific receiver or
passed to a listener where the association with a session is slightly
less immediate.
My personal preference is still for Session::reject(const Message&),
with the requirement that the message has been received on that session
(and not previously acknowledged) made very clear in the documentation.
However, clearly there are different views and it's not a deal-breaker
for me.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
