Modo de transação EJB padrão para methods asynchronouss?

  1. Quando tenho um método @Asynchronous em um EJB e não especifico o @TransactionAttribute , como exatamente o contêiner manipula os limites da transação? Obviamente, ele não pode usar a transação do segmento de chamada, então o que ele faz?

  2. Mesma pergunta, mas sobre methods que são acionados pelo TimerService.


EDIT: Eu acho que eu expressei isso mal. Eu já sei que o modo padrão é ‘REQUIRED’. Portanto, deve ser seguro assumir que esses methods sempre serão chamados em uma transação. Mas a minha pergunta é: como é o ciclo de vida dessa transação? O contêiner cria uma nova transação para cada chamada? Ou reutiliza a mesma transação para todas as chamadas em um thread de trabalho asynchronous? Se for o último, quando a transação será fechada?

Semelhante a um MDB, a transação é iniciada pelo contêiner imediatamente antes de seu @Asynchronous , @Schedule ou @Timeout (e interceptores aplicáveis) ser realmente invocado e confirmado logo após o método (e interceptores) ser concluído.

Como de costume, a transação se propaga para todos os beans chamados no método e todos os beans que esses beans chamam, recursivamente. É claro que outros beans invocados são bem-vindos para alterar a semântica de transação de sua chamada de método através da especificação de outras configurações de @TransactionAttribute (como NOT_SUPPORTED ou NOT_SUPPORTED ).

Nota lateral, as transactions nunca são propagadas para beans com @TransactionManagement(BEAN) . O contêiner sempre suspenderá qualquer transação em andamento antes de chamar um método em um bean Transaction-Managed Transaction.

De EJB 3.1 spec.

4.5.3 Transações

O contexto de transação do cliente não se propaga com uma chamada de método assíncrona. Do ponto de vista do Desenvolvedor Bean, nunca há um contexto de transação fluindo do cliente. Isso significa, por exemplo, que a semântica do atributo de transação REQUIRED em um método asynchronous é exatamente igual a REQUIRES_NEW.