Pourquoi regrouper les beans de session sans état?

Question

Les beans sans état de Java ne conservent pas leur état entre deux appels du client. Donc, en un mot, nous pourrions les considérer comme des objets avec des méthodes commerciales. Chaque méthode prend des paramètres et renvoie des résultats. Lorsque la méthode est appelée, certaines variables locales sont créées dans la pile d'exécution. Lorsque la méthode retourne les sections locales sont retirées de la pile et si certains objets temporaires ont été alloués, ils sont collectés de toute façon. De mon point de vue, cela ne diffère pas de la méthode d'appel de la même instance par des threads distincts. Alors, pourquoi un conteneur ne peut-il pas utiliser une instance d'un bean au lieu d'en regrouper plusieurs?

Answer 1

La mise en pool fait plusieurs choses. Un, en ayant un bean par instance, vous êtes sûr d'être threads sûr (Servlets, par exemple, ne sont pas thread-safe). Deuxièmement, vous réduisez le temps de démarrage potentiel d'un bean. Bien que les beans de session soient «apatrides», ils n'ont besoin que d'être apatrides en ce qui concerne le client. Par exemple, dans EJB, vous pouvez injecter plusieurs ressources de serveur dans un bean Session. Cet état est privé au bean, mais il n'y a aucune raison que vous ne puissiez pas le garder de l'invocation à l'invocation. Ainsi, en regroupant les beans, vous réduisez ces recherches à seulement lorsque le bean est créé. Troisièmement, vous pouvez utiliser le pool de bean comme moyen d'étrangler le trafic. Si vous n'avez que 10 Beans dans un pool, vous ne recevrez que 10 requêtes simultanées, le reste sera mis en file d'attente.

Answer 2

Le cycle de vie des beans session Statelesss n'existe pas, Passif et MethodReady (Passif ou Inactif). Pour optimiser la perormance, au lieu de traverser le bean de l'état de création à l'état prêt, le conteneur gère le bean actif et les états passifs via les rappels de conteneur - ejbActivate() et ejbPassivate() en gérant le pool de beans.

sreenut

Answer 3

Le regroupement améliore les performances. Une instance unique gérant toutes les demandes/tous les threads entraînerait beaucoup de conflits et de blocages.

Puisque vous ne savez pas quelle instance sera utilisée (et plusieurs threads peuvent utiliser une seule instance simultanément), les beans doivent être threadsafe.

Le conteneur peut gérer la taille du pool en fonction de l'activité réelle.

Answer 4

La transactionnalité du modèle Java EE utilise le contexte de thread pour gérer le cycle de vie des transactions.

Cette simplification existe de sorte qu'il n'est pas nécessaire d'implémenter une interface spécifique pour interagir directement avec l'objet UserTransaction; lorsque la transaction est extraite du InitialContext (ou injectée dans le bean session), elle est liée à une variable locale thread pour réutilisation (par exemple si une méthode dans votre bean session sans état appelle un autre bean session sans état qui utilise également une transaction injectée.