On 19/03/2012 17:47, Rüdiger zu Dohna wrote:
> Isn't this "transaction or request scope, whichever is longer" too complicated to understand (and implement)? I think
> it would be okay to stick to the transaction scope:
Thanks for your comments. I'm definitely open to suggestions and proposals here.
But if we adopted "transaction" scope (which we would still have to define), what would be the scope of MessagingContext
objects that were used outside of a transaction (e.g. if the entire method was called with no transaction).
Are you simply saying this is undefined, and that it is up to the container to decide when such objects were created and
closed? I don't think this is adequate (see my last point).
My proposals were an attempt to handle both the non-transacted and transacted cases.
> 1) If you have a transaction the message order is guaranteed to be stable, no matter what request or connection you
> send them from
I'm not sure that JMS 1.1 says this. It depends on whether you think that the last sentence of 4.4.10.2 overrides the
first sentence in the same section.
However if we adopt transaction scope (or my combined scope) it doesn't matter which way you interpret this, since the
application will be using the same session throughout the transaction, so message order is guaranteed.
> (it would be cool if you could get this guarantee even when you use different JMS providers within one
> transaction, but I guess that would be quite difficult to implement or standardize on, so I guess this guarantee is
> only valid within one JMS provider).
>
> 2) If you send messages outside of a transaction, they are sent immediately, so message order is guaranteed out of
> the box, isn't it?
Only if the messages are sent using the same session. 4.4.10.1. "Order of message receipt" says "JMS defines that
messages sent by a session to a destination must be received in the order in which they were sent...JMS does not define
order of message receipt... across a destination’s messages sent from multiple sessions.
That's why I think it is necessary to define the scoping behaviour of MessagingContext objects that are used outside of
a transaction, so applications can be sure whether they are using the same session or not.
Nigel