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.
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
>> 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
>>>
>>>
>>
>
>
> -----
> 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
>
>