Serviços como Transaction boundary

Oi Jadir,

Sobre o propagation/boundary eu colocaria o Service como Required e o Dao como Mandatory. Dessa forma o Dao seria chamado já com alguma transação corrente.

Abraços!

Mas é realmente uma boa prática? E projetos robustos com vários acessos simultâneos é viável se trabalhar assim

O padrão sugerido requer que o Service seja EJB, pois, sendo responsabilidade do container a instanciação, também é responsabilidade do container injetar o DAO como dependência, o que não aconteceria em uma instanciação manual. O mesmo vale para a relação entre o DAO e o PersistenceContext. Imagino que esse tipo de estrutura seja inclusive mais direcionada para uma aplicação robusta, uma vez que o container pode fazer uso dos pools de instâncias, o que diminui o esforço para instanciar cada Bean.

Quanto ao propagation/ boundary eu concordo com o Jadir. Tendo o DAO como Mandatory é possível conjulgar mais de uma chamada ao banco dentro da mesma transação. Favorecendo um possível rollback em conjunto. Já da outra forma, a atomicidade de cada chamada seria garantida, o que pode não ser desejável.

Posso utilizar o padrão Bean=>Service=Dao em uma aplicação mais robusta, disponibilizada para vários usuários? Nesse padrão:

O Service deve ser sempre uma classe EJB (Ex: @Stateless) ? O Dao e deve ser sempre uma classe EJB (Ex: @Stateless) ? Cada DAO deve ter o @PersistenceContext? ex: @PersistenceContext private EntityManager entityManager; Conforme a imagem, é ideal que os métodos do Service sejam MANDATORY (@TransactionAttribute(TransactionAttributeType.MANDATORY)) e os métodos do Dao sejam REQUIRED (@TransactionAttribute(TransactionAttributeType.REQUIRED))

Ou devo dar preferencia para REQUIRED nos dois tipos de classe?

Muito obrigado pela paciência as respostas que tenho recebido estão sendo muitíssimo esclarecedoras e determinantes para a tomada de decisão nas tecnologias que irei utilizar no meu próximo projeto

Oi Jadir,

Tanto o Dao quanto o Service devem ser EJBs. Em cada Dao deveria ter um PersistenceContext a não ser que você crie um Dao genérico onde o PersistenceContext é injetado e de onde os Daos filhos fariam uso (o que eu acho que é até mais desejável).

Quanto ao TransactionAttribute acho que você inverteu as bolas. Os métodos do Dao deveriam ser Mandatory e os do Service Required. Já o Bean não deveria nem se preocupar com o controle de transação.