John,
my understanding of what Reza suggested was that JMS should define a
*logical* scope of the bean being injected to be that of a transaction.
If CDI 1.1 and/or EJB 3.2 define a TransactionScope AND the JMS provider
uses CDI, that's a nice coincidence. But it may also very well be that
any JMS provider finds a different way to implement that scoped behavior
without CDI. Maybe even all JMS providers will have to find one, if CDI
1.1 isn't ready to define that scope out-of-the-box.
Rüdiger
On 09/06/2011 12:57 PM, John D. Ament wrote:
> Nigel, Reza,
>
> On Tue, Sep 6, 2011 at 4:50 AM, Nigel Deakin <nigel.deakin_at_oracle.com
> <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> Reza,
>
>
> On 06/09/2011 02:21, Reza Rahman wrote:
>
> Nigel,
>
> What I mean is that we do not actually need a standard scope
> defined in CDI, EJB or anywhere else. We can simply state
> that implementations will put the JMS objects in a scope that
> binds their life-cycle to the transaction, just like the
> JPA transactional persistence context. In practice, CDI-based
> implementations would end up creating a non-standard
> custom scope roughly equivalent to Resin's @TransactionScoped
> (CDI allows the creation of custom scopes).
>
> If the timing is correct, the @TransactionScoped concept could
> indeed be formally standardized in EJB/CDI, but this need
> not really be an external dependency for us. Trying to
> standardize that would likely delay our work and be of little
> practical value to JMS 2 users.
>
>
> I agree this would be a reasonable approach for JMS. However if
> we're going to invent our own scope we will need to define it
> clearly and unambiguously as part of JMS 2.0. I don't know difficult
> that would be. The overriding goal should be to ensure that
> applications which use the new annotations are portable between
> implementations. Having appropriate TCK tests would help with this.
>
>
>
> I think Nigel raises a strong point here. Since the concept of "scope"
> is defined in JSR-330 but the actual scope implementations and life
> cycle behavior is defined in CDI, something like this may end up driving
> a decision towards CDI vs. AtInject support in JMS 2.0. Basically, if
> we do want to define a scope within JMS 2.0 and guarantee its behavior
> and life cycle, then it must be against CDI, since scopes are meant to
> be implemented by the injector (the implementation of AtInject is called
> an injector in this case).
>
> John
>
>
> Nigel
>
>
>
> Cheers,
> Reza
>
>
> On 9/5/2011 6:00 AM, Nigel Deakin wrote:
>
> Reza,
>
> On 02/09/2011 23:13, Reza Rahman wrote:
>
> Nigel,
>
> You have it right. Responses below:
>
> * I agree that the built-in CDI scopes don't seem quite
> right for JMS objects. Your suggestion for a
> "transaction scope"
> sounds right. Do you have a definition of what such a
> scope would mean? It leaves me wondering why it's not
> already
> there as a built-in scope. Is this something we should
> take up with the CDI folks?
> - The simple definition of this scope is that objects
> live for the duration of the (JTA) transaction. Objects are
> materialized when the transaction begins and are
> destroyed when the transaction is
> committed/rolled-back/timed-__out.
>
> I think it is a very critical concept going forward,
> especially once you start thinking about developing
> transactional
> components that are not EJBs and do not have any
> implicit thread-safety guarantees. It's an idea we
> formulated at Caucho
> as we started decoupling the EJB services from the
> component model. JPA has a very similar concept, as does
> Spring
> although we first introduced the actual
> @TransactionScoped annotation in Resin. I did broach
> this topic with Pete (CDI
> 1.1 lead) and Marina (EJB 3.2 lead). The initial
> consensus was that this scope should be defined in EJB,
> potentially
> along with decoupling the transaction services from EJB.
> Given the current velocity of the EJB 3.2 EG, we have not
> gotten to discussing that in detail yet. At any rate,
> I'd offered to help the best I could with it. I'll
> discuss it
> again with them during JavaOne. It could definitely be
> helpful if you mention it as well.
>
> The point is though that we don't actually need this
> scope to be defined (in fact, we probably could not use
> it as-is
> anyway). What we need is the concept -- which has been
> there in JPA since EJB 3.0. A formal @TransactionScope
> is really
> more useful for end-users that should not be mucking
> around with the low-level JTA APIs Java EE is designed
> to shield
> them from.
>
>
> I don't quite follow your remark "we don't actually need
> this scope to be defined". Do you mean we don't need it to be
> decined in CDI, but we would need to define it for JMS?
>
> Would we be effectively defining a "standard" CDI custom scope?
>
> Nigel
>
>
> * You mean we should follow the model of a
> container-managed entity manager?
> - Yes, that's exactly what I mean. That model is
> entirely sufficient for this, with the additional
> concept of implicit
> inter-dependencies between objects in the JMS OO hierarchy.
>
> * Can you point me to the appropriate email in the archive?
> - The most relevant emails are here:
> http://java.net/projects/jms-__spec/lists/jsr343-experts/__archive/2011-07/message/46
> <http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2011-07/message/46>
> and here:
> http://java.net/projects/jms-__spec/lists/jsr343-experts/__archive/2011-07/message/58
> <http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2011-07/message/58>.
>
> Let me know if I need to clarify anything else.
>
> Cheers,
> Reza
>
>
> On 9/2/2011 1:42 PM, Nigel Deakin wrote:
>
> Reza,
>
> On 30/08/2011 21:58, Reza Rahman wrote:
>
> * The issue of correct scoping for the injected
> JMS objects is pretty critical to guaranteeing
> scalability across
> different container
> implementations/applications/__environments. I
> do know that Seam JMS currently has these injected
> objects in the dependent scope, in part because
> there is not yet a standard @TransactionScoped
> for CDI as of yet. The
> problem is that having these objects in the
> dependent scope will eventually cause the
> connection pool to run out if
> the
> objects are injected into very long-lived
> objects such as Servlets, pooled stateless
> session beans, singletons and
> application scoped services. This is basically
> the opposite problem of the connection thrashing
> that happens with
> Spring
> JmsTemplate.
>
>
> I agree that the built-in CDI scopes don't seem
> quite right for JMS objects. Your suggestion for a
> "transaction scope"
> sounds right. Do you have a definition of what such
> a scope would mean? It leaves me wondering why it's
> not already
> there as a built-in scope. Is this something we
> should take up with the CDI folks?
>
> JPA avoids this problem by making the
> persistence context transaction scoped by
> default and caching underlying
> logical sessions/connections per transaction
> (and limiting the extended persistence scope
> option to stateful session
> beans).
>
>
> You mean we should follow the model of a
> container-managed entity manager?
>
> > We can specify the same thing for injected JMS
> objects in addition to specifying inter-dependencies for
>
> intermediate JMS objects to maximize resource
> re-use.
>
>
> > For reference, I outlined the solution that we
> had for Resin in my initial detailed proposal.
>
> I'm not sure what particular proposal you're
> referring to. Can you point me to the appropriate
> email in the archive?
> (You can link to archived posts such as this:
> http://java.net/projects/jms-__spec/lists/jsr343-experts/__archive/2011-07/message/46
> <http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2011-07/message/46>
>
> Thanks,
>
> Nigel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3872 -
> Release Date: 09/02/11
>
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1392 / Virus Database: 1520/3872 - Release
> Date: 09/02/11
>
>
>
>