Rüdiger,
On 20/03/2012 13:30, Rüdiger zu Dohna wrote:
> I would leave the MessagingContext itself dependent scope. The underlying, eventually pooled Connection and/or
> Session should be shared by all MessagingContexts within one transaction, so they all are sent within the same
> transaction and in the guaranteed order.
This is a definition of transaction scope.
(I don't know whether it's necessary to describe the injected object as being dependent scope since it's just a proxy.
After all, a request-scoped object is just a proxy as well. But this is just a detail.)
> If there is no transaction available, every message is sent immediately with its own transaction/Session, and maybe
> even Connection.
OK. That's as small a scope as it would be possible to have. So
context.send(queue,payload1);
context.send(queue,payload2);
context.send(queue,payload3);
context.send(queue,payload4);
would use four different sessions (which means four different connections, since you can only have one session per
connection).
That's undesirable not only in terms of message ordering but resource usage.
(I don't dispute that the message is "sent immediately" - that's not at issue here. What matters is how the JMS provider
handles it)
> The spec may be not perfectly clear, as it seems to refer to different threads or even different
> clients using different sessions... message order is not guaranteed then.
Indeed, it isn't, whereas if the context has a longer scope (request, say) then message order *would* be guaranteed.
Defining such a short scope offers only disadvantages and no advantages.
> But here one thread sends multiple messages
> while opening and closing a separate session for each message. I would be surprised, if any JMS provider would mess
> up ordering in this case.
No, if messages are being sent using separate sessions (and especially when using separate connections) then we *can't*
make any assumptions about message order. That's one of the basic principles on which the architecture of JMS providers
is based.
(At the risk of digressing, if message order was defined by producer thread rather than by producer session then this
would force JMS providers to do lots of things that they are not currently required to do. For example all connections
created in a thread would need to be processed by the same server-side thread (whereas currently they can all be
processed by separate threads). And if the JMS provider were clustered it would prevent the client load-balancing
connections and instead force all connections created in a thread to connect to the same JMS server.)
Nigel
>
> On 2012-03-20, at 14:03, Nigel Deakin wrote:
>> 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
>