users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Transactions, EJBs and AsyncResponse

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 24 Oct 2012 15:01:49 -0400

Jan,
 
 Checked with Marina who is the EJB spec lead. Some relevant text:

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