Estou estudando formas de implementação de padrões de desenvolvimento para nossa equipe, onde partimos como definição o ingresso completo na arquitetura Java EE 6 com container de aplicação.
Dentro do estudo definimos a necessidade da implementação do pattern DAO, e uma das possibilidades é implementar os DAOs como stateless session beans.
Isto posto venho perguntar a opinião ou experiência de vocês, da opção como session bean ou não session bean, quanto a estes pontos ou algum outro ponto que considere relevante:
A camada de persistência envolve outros tipos de fontes de dados, mas falando especificamente de banco de dados: JPA gerenciado pelo container com injeção de dependência.
A implementação da camada de negócio envolve session beans (sem e com interfaces locais e remotas) e classes auxiliares.
Acredito que a forma de realização das perguntas dificultou a participação nesta discussão, então retorno ao tópico para tentar modificar a forma de questionamento. Como primeira mudança, irei abordar apenas uma das questões e explicitarei as minhas conclusões até o momento sujeitando estas conclusões às análises e correções do pessoal.
Questão 3. Concorrências de instâncias.
A forma de uso mais comum que se encontra em tutoriais, de uso do entitymanager, é a seguir:
@Stateless
public class NegocioSessionBean { // classe de negocio (*SB)
@PersistenceContext
private EntityManager entitymanager; // atributo a ser injetado (*EM)
}
Desta forma, temos um SB que será instanciado a medida que o container acredita ser necessário e inserido no pool. Como temos a injeção de dependência do EM, temos dentro da instância do SB uma conexão com o banco reservada para este SB.
Extrapolando, digamos que o uso mais comum implique em 10 instâncias do SB no pool, isto significa 10 conexões com o banco abertas apenas para atender estes SBs?
A forma de uso que tenho como proposta seria:
[code]@Stateless
public class NegocioSessionBean { // classe de negocio @EJB
private EntityDAOSessionBean entitydaosessionbean; // atributo a ser injetado (*DAO)
}
@Stateless
public class EntityDAOSessionBean { // classe concentradora de acesso a dados @PersistenceContext
private EntityManager entitymanager; // atributo a ser injetado
}[/code]
Desta forma, temos um DAO e um SB que serão instanciados a medida que o container acredita ser necessário e inseridos nos respectivos pools. Como temos a injeção de dependência do DAO, temos dentro da instância do DAO uma conexão com o banco reservada para este DAO. Da mesma forma cada instância no pool do SB terá uma instância reservada do DAO.
Extrapolando aqui, ainda teríamos a mesma reserva de conexões para cada SB no pool. Correto?
O dilema é a reserva de conexões com o banco, que acredito serem o recurso mais precioso em nosso ambiente, uma opção seria transformar os DAOs em classes normais a serem criadas quando necessário, trocando o custo da reserva de conexão pelo custo de criações constantes de instâncias do DAO. Mas, é claro, isto depende se o meu entendimento, até agora, esteja correto ou equivocado.
No meu entender você pode ter o DAO como Session Bean porque o contexto de persistência (EntityManager) é propagado para evitar a necessidade de ficar passando ele por parâmetro. Porém eu não sei como são gerenciados as conexões com o banco (nos EntityManagers) no POOL de instâncias do servidor de aplicação…
[alguém por favor me corrija se eu estiver errado pois não sou especialista em JPA].