Pourquoi regrouper des beans de session sans état?

Question

Les beans sans état en Java ne conservent pas leur état entre deux appels du client. En résumé, nous pourrions les considérer comme des objets dotés de méthodes d’affaires. Chaque méthode prend des paramètres et renvoie des résultats. Lorsque la méthode est appelée, des variables locales sont en cours de création dans la pile d'exécution. Lorsque la méthode retourne, les sections locales sont supprimées de la pile et, si des objets temporaires ont été alloués, elles sont néanmoins récupérées.

De mon point de vue, cela ne diffère pas de la méthode d’appel de la même instance unique par des threads distincts. Alors, pourquoi un conteneur ne peut-il pas utiliser une seule instance d'un bean au lieu de regrouper plusieurs d'entre eux?

Answer 1

Le regroupement fait plusieurs choses.

Premièrement, en ayant un bean par instance, vous êtes assuré que les threads sont sûrs (les 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 Session Beans soient "sans état", ils doivent seulement être sans état vis-à-vis du client. Par exemple, dans EJB, vous pouvez injecter plusieurs ressources de serveur dans un bean session. Cet état est privé au haricot, mais rien ne vous empêche de le garder d'invocation à invocation. Ainsi, en regroupant les haricots, vous réduisez ces recherches à la création du haricot uniquement.

Troisièmement, vous pouvez utiliser le pool de haricots comme moyen de limiter le trafic. Si vous ne disposez que de 10 Beans dans un pool, vous ne pourrez que faire fonctionner au maximum 10 requêtes simultanément, le reste sera mis en file d'attente.

Answer 2

Le regroupement améliore les performances.

Une seule instance traitant toutes les demandes / threads entraînerait beaucoup de conflits et de blocages.

Etant donné que vous ne savez pas quelle instance sera utilisée (et que plusieurs threads pourraient 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 3

Le caractère transactionnel du modèle Java EE utilise le contexte de thread pour gérer le cycle de vie de la transaction.

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 de InitialContext (ou injectée dans le bean de session), elle est liée à une variable locale de thread pour être réutilisée (par exemple, si une méthode de votre bean de session sans état appelle un autre bean de session sans état qui utilise également une transaction injectée. )

Answer 4

Le cycle de vie des beans de session Statelesss n’existe pas, il est passif et MethodReady (passif ou inactif). états passifs via les rappels de conteneur - ejbActivate () et ejbPassivate () à cet emplacement en gérant le pool de beans.

sreenut

Answer 5

Les méthodes, par nature, sont sécurisées pour le fil (y compris statique). Pourquoi? Simple, car chaque variable de la méthode est créée dans la mémoire de pile, c’est-à-dire que chaque variable utilisée dans la méthode est créée par appel (elle n’est pas partagée). Cependant, les paramètres ne font pas partie de la pile.

Cependant, une méthode est non sécurisée si elle utilise une variable non sécurisée:

a) appelant un champ statique ou une variable. Cependant, cela se produit dans tous les cas.

b) appeler une ressource qu’elle partage. Tels que le EntityManager.

c) passer un paramètre qui n’est pas sûr.