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.
* 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
and here:
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
>
>
> Thanks,
>
> Nigel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3872 - Release Date: 09/02/11
>
>