On 3/20/2012 9:30 AM, 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.
>
> If there is no transaction available, every message is sent immediately with its own transaction/Session, and maybe even Connection. 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. 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.
This was my initial thought also. In fact, it would work fine in Java EE
because of the restrictions on JMS. The trouble is that it breaks down
if we try to use JMS context injection in Java SE and expect to use
things like commit() and rollback().
I'm still trying to make some time to get some much needed traction
behind the CDI transaction scope (which I think will need to be
inherently somewhat complex in order to be usable/robust). I'm hoping to
at least get that properly revived this week and get Pete whatever he needs.
>
> 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
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2114/4880 - Release Date: 03/19/12
>
>
>