Default EJB transaction mode for asynchronous methods?

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?

Solution 1

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.

EDIT:

Answering the edited question more directly; there are no means via the Java Transaction API to have one transaction span several threads and therefore no means in EJB. Every @Asynchronous call is completely disconnected from the caller's transaction (if any). You will essentially get either a new transaction, no transaction, or an exception depending on what @TransactionAttribute you used. Same with any calls from the TimerService.

Solution 2

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.

Comments

[BillMan]

Please be aware that this answer seems to be contrary to the answer below (may depend on EJB version).

[David Blevins]

@BillMan Let me know where things appear to conflict and I'll update the answer to clarify.

[BillMan]

@DavidBlevins My bad, I misunderstood your original answer. There doesn't appear to be any conflict now that I read it again. I can delete the original if you like.. It might be good for my humility if you keep it there though :).

[David Blevins]

@BillMan Hehe, no worries. Fun exchange. If you had to read it twice, it's still probably my fault. :)

[dngfng]

Great answer, also had to read it twice. For every one else reading this (as stated above and below). A new Transaction is started for the asynchronous method.

[gmanjon]

Just for everyone to know. David Blevins (the answerer here) is a Java Champion that works in the specification of EJB (among others, like CDI. linkedin.com/in/dblevins). So every answer that you read from him can be considered source of truth :) Thanks David