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