--
4.5.3Transactions
The client’s transaction context does not propagate with an asynchronous method invocation. From the Bean Provider’s point of view, there is never a transaction context flowing in from the client. This means, for example, that the semantics of the REQUIRED transaction attribute on an asynchronous method are exactly the same as REQUIRES_NEW.
--
 So it's REQUIRES_NEW in this case, and you can override it to make it non-transactional. AFAICT, there's nothing we need to say/clarify about this in our spec.
-- Santiago
On Oct 23, 2012, at 10:34 AM, Jan Algermissen wrote:
> 
> On Oct 23, 2012, at 4:28 PM, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> wrote:
> 
>> 
>> On Oct 20, 2012, at 12:10 PM, Jan Algermissen wrote:
>> 
>>> In 7.3 the spec points out the use of @Asynchronous.
>>> 
>>> I wonder whether it would ne nice to also point out that the default transaction type of @Asynchronous is to run the annotated method in the same transaction and that requiring a new transaction for the given scenarios is required to really detach the response creation.
>> 
>> Interesting, I didn't think about that at all. Could you elaborate the problem that results from _not_ creating a new transaction in this case?
> 
> I am not the expert (Hello @adambien ?) but the transaction that the request handling started in will stay open until the asynchronous method returns. Not sure what the implication on the request-handling thread is. Is the transaction 'owning' that thread or is it detached?
> 
> Just wondered whether/how executing the asynchronous (long running) method in the same transaction (the default) will affect the request handling thread - and whether it leads to the same blocking that actually is intended to be avoided.
> 
> Jan
> 
> 
>> 
>> Thanks.
>> 
>> -- Santiago
>> 
>