Rüdiger,
On 20/03/2012 15:25, Rüdiger zu Dohna wrote:
> On 2012-03-20, at 15:45, Nigel Deakin wrote:
>> 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.
>
> Except for different instances of the MessagingContext may be configured to use different delivery modes, delivery
> delays, priorities, etc.
So far the only things you can define at the injection point are connection factory, session mode, auto-start behaviour
and user/password. (See Early Draft for details).
If two injection points use, say, different connection factories, then the injected instances will always represent
different MessagingContext objects, which I think is the point you are making.
Currently delivery mode, delivery delay, priority, timeToLive are defined using normal API methods, though we could make
these annotation parameters as well if people think this is a good idea.
>
>> (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.
>> ... That's undesirable not only in terms of message ordering but resource usage. ... [many more good points
>> snipped]
>
>
> You are perfectly right, even with pooled connections, this is not really desirable.
>
> Maybe a MessagingContexts would use a separate Session as long as no transaction is available?
Can you expand on this suggestion?
> Would you expect
> guaranteed message order, if you use different MessagingContexts and no transactions?
No. You only have message order if you send messages using the same MessagingContext (session).
>
> I'm insisting on this point, because I don't want to have to explain to developers how those two scopes interrelate
> to each other...
My proposal was for just a single scope, which was defined in terms of the start and end of the request, and the start
and end of the transaction. I'm not suggesting two scopes (though that would be an alternative possibility).
> I just think there *must* be some way to handle that with *one* scope, namely transaction scope,
> while without any scope, only a "local" transaction is available with only message ordering guaranteed locally to
> that context.
Does CDI have the concept of using an injected object "without any scope"? It seems to me that this would be something
new. If we're going to allow such objects to be used in such cases (rather than throw an Excrption), then we still have
to define when the MessagingContext is created and disposed - in which case it *does* have a scope.
(Since we seem to be going round in circles, I'd be happy to chat about this on the phone, either directly or with others)
Nigel