> >> 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.
I think this is not true. In case of REQUIRES_NEW set at the @Asynchronous
method, the original TX can be closed (depending on the setting of the
calling method) before the asynchronous operation is finished, as the
background method will start a new TX anyways.
> Not sure what the implication on the request-handling
> thread is. Is the transaction 'owning' that thread or is it detached?
A TX never "owns" a thread. Threads and TX are completely decoupled and can
have completely different life cycles. A thread simply "references" a
transaction, and even this is optional, since a thread can run untransacted,
or be pooled, etc. A TX is nothing but a marker temporarily respected by a
running thread.
> 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.
The thread is not affected at all by the TX management. If the same TX is
used, this simply prevents the EJB container from terminating the TX at then
end of the calling method (the thread typically will not end anyways but
simply is pooled). If a different TX is used, the container *may* close the
original TX. But the thread plays no role.
>
> Jan
>
>
> >
> > Thanks.
> >
> > -- Santiago
> >