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.