É seguro para injetar um EJB em um servlet como uma variável de instância?

Question

Todos nós sabemos que na camada web, há a possibilidade de que apenas uma única instância de uma determinada Servlet existe quais serviços várias solicitações. Isso pode levar a enfiar questões em variáveis ??de instância.

A minha pergunta é, será que é seguro para injetar um EJB usando a anotação @ EJB em um servlet como uma variável de instância?

O meu instinto inicial seria, sem ser, sob a suposição de que a mesma instância do EJB iria atender vários pedidos ao mesmo tempo. Parece que este também seria o instinto de uma série de outros programadores: não injectar a servlets

No entanto tenho chegado à conclusão errada. Claramente o que é injetado no servlet é um proxy, sob o capô que o recipiente realmente atender cada pedido com uma instância diferente e manter a segurança do thread? Como este fórum sugeriria: Do injetar a servlets

Parece haver um monte de opiniões conflitantes. O que é correto ???

Answer 1

A sua referência "Não injectar a servlets" menciona nada sobre ejbs ou anotação @ejb. É sobre não fala enfiar objetos seguros, como PersistenceContext.

Por EJB especificação você pode acessar ejbs da variedade de clientes remotos, incluindo servlets (EJB 3.0 Specification (JSR-220) - Seção 3.1). Injectar ejb usando anotação @EJB é um método de obtenção de interface EJB via injecção dependência (secção 3.4.1), que é uma alternativa ao olhar-se objectos ejb no espaço de nomes JNDI. Então não há nada de especial sobre anotação @EJB com respeito a EJBs obtidos.

Assim, com base em EJB 3.0 Spec, é uma prática padrão para obter ejbs de servlets usando a anotação @ EJB.

Answer 2

É seguro para injetar um EJB em um servlet como uma variável de instância Servlet, enquanto o EJB é apátrida. Você nunca deve injetar um feijão Stateful em um servlet.

Você deve implementar seu apátrida EJB em que ele não mantém qualquer variável de instância que se mantém um valor stateful (como Persistência Contexto). Se você precisa usar o contexto de persistência, então você deve obter uma instância dele nos métodos do EJB. Você pode fazer isso por ter um PersistenceContextFactory como uma variável de instância EJB e então você obtém uma instância do gerenciador de entidades da fábrica no método do EJB.

O PersistenceContextFactory é isenta de segmentos, assim pode ser injectado em uma variável de instância.

Enquanto você cumprir com o acima exposto regras mencionadas, deve ser thread-safe para injetar um bean Stateless em um Servlet

Answer 3

É um saco misturado.

Stateless Session Beans pode ser injetado e são seguros. Isso porque, mesmo se uma única instância de um esboço é usado, o acesso aos métodos será serializado pelo contêiner.

Eu acho que o inferreddesign diz é não é verdade . Não importa se o bean de sessão sem estado usa um contexto de persistência. Apenas um chamador nunca terá acesso a uma única instância de feijão, ao mesmo tempo, por isso mesmo que o contexto de persistência não é thread-safe, os guardas EJB contra múltiplo acesso a ele. Pense nisso como se cada método session bean tem a palavra-chave sincronizado aplicada a ele.

O principal problema com injetar um EJB em um servlet eu acho que é o desempenho. A instância esboço single vai se tornar uma grande área de contenção quando vários pedidos estão na fila enquanto espera por um método de bean de sessão para ser executado por eles.

Answer 4

Eu acho que a resposta simples é que você não está garantido que ele é seguro.

A razão para isto é que não há nada explícito na especificação EJB que diz interfaces de EJB casa tem que ser thread-safe. A especificação descreve o comportamento de apenas a parte do lado do servidor. O que você provavelmente vai encontrar é que os esqueletos de clientes são, na verdade, o segmento de seguros, mas você precisa olhar para como eles são implementados pela biblioteca que você está usando. A parte anotação só vai expandir-se para um localizador de serviço para que não compra nada.