[jms-spec users] [jsr343-experts] Re: (JMS_SPEC-70) Define annotations for injecting MessagingContext objects
- From: Nigel Deakin <nigel.deakin@...>
- To: jsr343-experts@...
- Subject: [jms-spec users] [jsr343-experts] Re: (JMS_SPEC-70) Define annotations for injecting MessagingContext objects
- Date: Mon, 11 Jun 2012 12:37:57 +0100
- List-id: <jsr343-experts.jms-spec.java.net>
(Sorry for the delay in responding, I was away last week).
On 2012-06-01, at 21:05, Reza Rahman wrote:
I do think we should reconsider separate JMSContext instance for every
injection point. It's likely overkill with
the updated definition of the transaction scope and would otherwise simplify
matters from a JMSContext
Can you please elaborate on your thinking here?
As I wrote on the use cases page, the reason for having a separate JMSContext instance for every injection point was to
avoid confusing the user by having two methods in separate beans, with separate instance variables, use the same
JMSContext instance if they were called within the same scope. I got the feedback that this would be simply too
"surprising" for users.
On 03/06/2012 21:10, Rüdiger zu Dohna wrote:
> If I understand it correctly, the scope can't simple be dependent, because
then the connection/session would not be
> closed after use. So it's not about extending the lifetime but about
Yes, that's why we can't simply make it simply dependent scope.
> The actual instance injected (Nigel
> calls this a proxy, as it just forwards most calls) will be dependent
scoped, but the underlying connection/session
> must be transaction scoped.
> Maybe we could find a better wording to explain this?
Currently I am proposing that the "proxy" is dependent scoped, and the underlying JMSContext is transaction scoped. The
need for a dependent-scoped proxy is simply a implementation detail to allow applications to specify parameters such as
JNDI name at the injection point.
However I think there is an alternative which you (Rüdiger) suggested some time ago, which merits airing again, which
would avoid the need for the "separate JMSContext instance for every injection point" restriction whilst avoiding the
main cause of confusion caused by following normal CDI sharing rules. I'll call this the "splitting the JMSContext
option", and describe it - in my own words - here:
Splitting the JMSContext option
(For the avoidance of doubt, this is not part of my current proposal, but I
am raising it here as a possible alternative):
One way to avoid the need for the "separate JMSContext instance for every injection point" restriction might be to
separate a JMSContext into two objects internally which have different scopes.
A JMSContext would consist of two objects:
1. JMSContextState: contains the deliveryMode, priority, timeToLive,
2. JMSContextSession: contains the connection, session and producer (but not its deliveryMode, priority, timeToLive,
Applications would never handle JMSContextState and JMSContextSession objects directly. They would simply be internals
of the JMSContext. However:
The JMSContextState would be "dependent" scope, and
the JMSContextSession would be "transaction" scope
The parent JMSContext would be "dependent" scope.
This would allow the sharing of the transactional and message order state between beans, but not deliveryMode, priority,
timeToLive and deliveryDelay, thereby avoiding the main cause of confusion.
This might be a compromise which:
1. allows us to avoid the most potentially-confusing aspect of sharing a JMSContext between two beans, which is setting
(say) a deliveryMode in one bean and affecting the behaviour in another bean.
2. allows us to close the underlying session and connection after use
3. avoids the use of the same underlying session and connection in two separate transactions (one suspended), which is a
use case which JMS currently doesn't define.
I'm not sure how we would describe this to users. Effectively we would be saying "the JMSContext has transaction scope,
but with a separate deliveryMode, priority, timeToLive, deliveryDelay for each injection point".
Do you think this variation has merit?