Ok, so following up on this a bit. I still don't think that JMSDeliveryMode can be varied on an operation by operation basis
I can just about buy the point about transaction being specified on and operation by operation basis but it's not clear that the spec is excplicity about this. Also seems like a strange thing to do. So putting these two issues aside it is still the case that we would have to store the JMS resources on a thread by thread basis. For stateless components this should be straighforward as a new component instance is created for each thread. We'd have to change the way the JMS binding works in order to cache the JMSContext on the basis of the invoker as opposed to each invoke. For composite scoped components things are a little different as multiple threads can be active in the same component instance at the same time. We would have to have a cache of JMSContext in the invoker indexed by thread. We would also need some code in the implementation invoker to clear the cache, and hence release the JMS resources, when the thread of control leaves the component. It feels like the same solution will work in both stateless and stateful cases but we would end up with a bit of over engineering of the cache in the stateless case. Probably better to aim for consistency over scope specificity in the binding though. Thoughts anyone? Simon
