Est-il prudent d’injecter un EJB dans une servlet en tant que variable d’instance?

Question

Nous savons tous que dans la couche Web, il est possible qu’il ne subsiste qu’une seule instance d’un servlet donné répondant à plusieurs demandes. Cela peut entraîner des problèmes de thread dans les variables d'instance.

Ma question est la suivante: est-il prudent d'injecter un EJB utilisant l'annotation @EJB dans un servlet en tant que variable d'instance?

Mon instinct initial serait non, en supposant que la même instance de l'EJB traiterait plusieurs demandes en même temps. Il semblerait que ce soit aussi l'instinct d'un certain nombre d'autres programmeurs: Ne pas injecter dans les servlets

Cependant, j’ai sauté à la mauvaise conclusion. Il est clair que ce qui est injecté dans la servlet est un proxy. Sous le capot, le conteneur traite-t-il réellement chaque requête avec une instance différente et maintient-il la sécurité des threads? Comme ce forum le suggère: injecter dans des servlets

Il semble y avoir beaucoup d’opinions contradictoires. Ce qui est correct ???

Answer 1

Votre référence "Ne pas injecter dans les servlets". ne mentionne rien à propos des ejbs ou des annotations @ejb. Il parle d’objets non sécuritaires comme les threads tels que PersistenceContext.

Selon les spécifications EJB, vous pouvez accéder aux ejbs de nombreux clients distants, y compris des servlets (spécification EJB 3.0 (JSR-220) - Section 3.1). L'injection de ejb à l'aide de l'annotation @EJB est une méthode permettant d'obtenir une interface EJB via une injection de dépendances (section 3.4.1), alternative à la recherche d'objets ejb dans l'espace de noms JNDI. L'annotation @EJB n'a donc rien de spécial en ce qui concerne les EJB obtenus.

Donc, basé sur la spécification EJB 3.0 Spec, il est courant d’obtenir des ejbs à partir de servlets en utilisant l’annotation @EJB.

Answer 2

Il est prudent d’injecter un EJB dans un servlet en tant que variable d’instance de servlet, tant que l’EJB est sans état. Vous NE DEVEZ JAMAIS injecter un Bean Stateful dans un Servlet.

Vous devez implémenter votre EJB sans état, car il ne contient aucune variable d'instance qui contient elle-même une valeur avec état (comme Persistence Context). Si vous devez utiliser le contexte de persistance, vous devez en obtenir une instance DANS les méthodes de l'EJB. Vous pouvez le faire en utilisant une PersistenceContextFactory en tant que variable d’instance EJB, puis vous obtenez une instance du gestionnaire d’entités de la fabrique dans la méthode de l’EJB.

PersistenceContextFactory est thread-safe, il peut donc être injecté dans une variable d'instance.

Tant que vous respectez les règles mentionnées ci-dessus, l'injection d'un bean sans état dans un servlet doit être sécurisée pour les threads.

Answer 3

C'est un sac mélangé.

Des beans session sans état peuvent être injectés et sont sûrs. En effet, même si une seule instance d'un stub est utilisée, l'accès aux méthodes sera sérialisé par le conteneur.

Je pense que ce que dit le concept inféré est: pas vrai . Peu importe que le bean session sans état utilise un contexte de persistance. Un seul appelant n'accédera jamais à une seule instance de bean en même temps. Ainsi, même si le contexte de persistance n'est pas thread-safe, l'EJB protège contre les accès multiples. Pensez-y comme si le mot-clé synchronized était appliqué à chaque méthode de session-haricot.

Je pense que le principal problème lié à l'injection d'un EJB dans un servlet est la performance. L’instance de stub unique deviendra un sujet de discorde majeur lorsque plusieurs demandes se mettront en file d'attente pendant qu'elles attendent l'exécution d'une méthode de bean session.

Answer 4

Je pense que la réponse simple est que vous n'êtes pas assuré que tout est en sécurité.

La raison en est qu’il n’existe aucune explication dans la spécification EJB selon laquelle les interfaces de base EJB doivent être thread-safe. La spécification décrit le comportement de la partie côté serveur uniquement. Ce que vous constaterez probablement, c’est que les squelettes des clients sont réellement thread-safe, mais vous devrez également regarder comment ils sont mis en œuvre par la bibliothèque que vous utilisez. La partie annotation deviendra simplement un localisateur de service, de sorte que cela ne vous achète rien.