Nigel,
On 2012-03-20, at 17:35, Nigel Deakin wrote:
> 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 didn't mean to set them by annotations... just with the normal API methods. If you access two bean instances in one request or transaction, the JMSContexts injected into each bean will be different instances, when the context is dependent scoped, but the same instance, when it's transaction or request scoped. Setting any of those properties from one bean would affect the other! So the JMSContext should really be dependent scoped and only the session (and thereby the connection) should be shared within one transaction if there is one... or use separate sessions if there is none, i.e., every JMSContext would open and use a session private to this context, when it needs one and no transaction scoped session is available.
>>> (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?
see above
>> 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).
... or within one transaction, because then your JMSContexts share one transaction scoped 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).
But the behavior of that scope is not yet completely defined. I would currently describe it to be a mixture of dependent and transaction scope.
>> 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)
very true... mail discussions are always difficult... I'd too be happy to chat with you again... tomorrow would be perfect at any time (my first complete day without any meetings for months :-)
Rüdiger