I'm fine with that additional clarification.
Regards,
Fred Rowe
WebSphere Architect
Senior Software Engineer
IBM Software Group
frowe_at_us.ibm.com
Anthony Lai <anthony.lai_at_oracle.com>
02/15/2013 03:51 PM
Please respond to
jsr236-experts
To
jsr236-experts_at_concurrency-ee-spec.java.net
cc
Subject
[jsr236-spec users] [jsr236-experts] Transaction discussion from JSR 342
[was Re: JSR 236]
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.
>
>