jsr236-experts@concurrency-ee-spec.java.net

[jsr236-experts] Transaction discussion from JSR 342 [was Re: JSR 236]

From: Anthony Lai <anthony.lai_at_oracle.com>
Date: Fri, 15 Feb 2013 12:51:46 -0800

Dear Experts,

Forwarding a discussion on the JSR 342 (EE 7 Platform) expert group. It
is suggested that:

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.

Currently, the spec only specified that
javax.transaction.UserTransaction should be available for the tasks
should they wish to use transaction. Does anyone see any problem with
adding to the spec what was suggested in the JSR 342 discussion?

Regards
Anthony

-------- Original Message --------
Subject: Re: JSR 236
Date: Thu, 14 Feb 2013 14:01:55 -0800
From: Bill Shannon <bill.shannon_at_oracle.com>
To: Anthony Lai <ANTHONY.LAI_at_oracle.com>
CC: jsr342-experts_at_javaee-spec.java.net



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