Default EJB transaction mode for asynchronous meth

Question

1. When I have an @Asynchronous method in an EJB, and I don't specify the @TransactionAttribute, then how exactly does the container handle the transaction boundaries? Obviously, it can't use the calling thread's transaction, so what does it do?

2. Same question, but regarding methods that are triggered by the TimerService.

---

EDIT: I think I phrased that poorly. I already know that the default mode is 'REQUIRED'. So it should be safe to assume that those methods will always be called within a transaction. But my question is, what does that transaction's life-cycle look like? Does the container create a new transaction for each call? Or does it re-use the same transaction for all the calls on an asynchronous worker thread? If it's the latter, then when does the transaction get closed?

Answer 1

From EJB 3.1 spec.

4.5.3 Transactions

Client transaction context does not propagate with an asynchronous method invocation. From the Bean Developer’s 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.

Answer 2

Similar to an MDB the transaction is started by the container just before your @Asynchronous, @Schedule or @Timeout method (and applicable interceptors) is actually invoked and committed just after the method (and interceptors) completes.

As per usual, the transaction propagates to all beans called in said method and all beans those beans call, recursively. Of course other beans invoked are welcome to change the transaction semantics of their method call via specifying other @TransactionAttribute settings (say REQUIRES_NEW, or NOT_SUPPORTED).

Side note, transactions are never propagated to beans with @TransactionManagement(BEAN). The container will always suspend any transaction in progress before invoking a method on a Bean-Managed Transaction bean.