That's a good point, but I contend that it is not likely to happen that
often and folks are already "used to" this slight idiosyncrasy because this
is how JPA context propagation works today (as you know). This being said, I
do really like your idea of splitting the JMS context state and
connection/session -- it seems like a very elegant solution.
BTW, I suspect the effort to standardize the transaction scope is unlikely
to happen in a timely fashion (this is my second attempt at it in the CDI EG
and things seem to stall both times for various somewhat inexplicable
reasons). I think we should consider simply defining a JMS context specific
scope to keep things moving along and see if that can be adopted by the CDI
EG (or some other EG) at some later point in time. As such, this is the
precedent in JPA, JSF, etc anyway.
> -----Original Message-----
> From: Nigel Deakin [mailto:nigel.deakin_at_oracle.com]
> Sent: Monday, June 11, 2012 7:38 AM
> To: jsr343-experts_at_jms-spec.java.net
> Subject: [jsr343-experts] Re: (JMS_SPEC-70) Define annotations for
injecting
> MessagingContext objects
>
> (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 implementation standpoint.
>
> 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:
> > Reza,
> >
> > 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 limiting it!
>
> 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,
> deliveryDelay 2. JMSContextSession: contains the connection, session and
> producer (but not its deliveryMode, priority, timeToLive,
> deliveryDelay)
>
> 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?
>
> Nigel
>
>