Queria fazer um teste para ter uma outra visão a respeito do escopo transacional dos sessions beans, e para tal, fiz o teste descrito abaixo:
- Retirei o conteúdo do método "enviarEmail" do AgendamentoEmailJob e o coloquei no AgendamentoEmailResource, fazendo uma pequena alteração. Coloquei-o no "listar" mesmo, só pra fins de testes. Ficou dessa forma:
@GET
@Produces(value = MediaType.APPLICATION_JSON)
public Response listar() {
List<AgendamentoEmail> listaEmailsNaoAgendados
= agendamentoEmailServico.listarPorNaoAgendado();
listaEmailsNaoAgendados.forEach(emailNaoAgendado -> {
//agendamentoEmailServico.enciar(emailNaoAgendado);
agendamentoEmailServico.alterar(emailNaoAgendado);
});
return Response.ok(agendamentoEmailServico.listar()).build();
}Ao fazer a requisição para esse método, a rotina é executada e no banco de dados, o resultado é o mesmo quando se faz a anotação "@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)" (apenas alguns registros são alterados).
A conclusão na qual cheguei é: sempre que um Session Bean utiliza outro, o contexto transacional sempre fica com o session bean que "faz a chamada" (não vou chamar de pai pra não confundir com herança), e esse comportamento faz com que, caso haja uma sequência de alterações no banco de dados, se houver alguma exceção no session bean que "recebeu o chamado", todas as alterações sofrem rollback, como demonstrado no vídeo.
Porém, caso essa sequência de alterações seja solicitada por um outro componente que não seja um session bean (ex: um resource JAX-RS), o contexto transacional fica somente no método que recebeu a solicitação e faz parte de um session bean.
Gostaria apenas de saber se o raciocínio está correto, porque procurei na documentação, mas não encontrei.
Desde já, muito obrigado!
