users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: JSR 236

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 14 Feb 2013 14:01:55 -0800

Anthony, please make sure the JSR 236 spec is clear that tasks/threads
have the same ability to use transactions that the component submitting
them does. For example, they can call transactional enterprise beans,
they can call managed beans that use the @Transactional interceptor,
they can start their own transactions using UserTransaction, etc.

Thanks.

Pete Muir wrote on 02/14/2013 06:35 AM:
>
> On 14 Feb 2013, at 00:58, Bill Shannon wrote:
>
>> Pete Muir wrote on 02/12/13 06:37:
>>>>> * support injecting a default managed executor services using @Inject
>>>>> natively
>>>>
>>>> This is just another example of the "default producers" issue we've
>>>> discussed, and which we decided not to address for this release, but would
>>>> like to address in the future.
>>>
>>> I would disagree. In some cases a default producer makes sense, in others it
>>> doesn't. Here it does, so we should support it. Just because something
>>> doesn't always make sense isn't a reason to never do it.
>>
>> I agree. And I agree that we should support it, once we have a general
>> strategy for supporting default producers. There are other cases that
>> make sense as well, but that we deferred because we hadn't worked through
>> all the technical issues. I'd like to see us do that for EE 8.
>>
>>>>> * Support for @Transactional as well as EJB transactions
>>>>
>>>> I don't understand the issue here. I would expect that tasks support these
>>>> in the same way that other classes support them.
>>>
>>> Right, however the spec could show this.
>>
>> I don't think the JSR 236 spec needs examples showing tasks doing all the
>> things that a Java EE application class can do.
>>
>> Is there some reason you think it especially needs an example of
>> @Transactional?
>>
>> If you think there's any question about whether tasks can use transactions
>> at all, we could clarify that.
>
>
> Right, this is the reason I am suggesting it.
>
>