Conteneurs EJB
Un conteneur EJB (Enterprise JavaBeans) fournit un environnement d'exécution pour les beans enterprise sur un serveur d'applications. Le conteneur gère tous les aspects du fonctionnement des beans enterprise sur le serveur d'applications et fait office d'intermédiaire entre la logique métier utilisateur dans le bean et le reste de l'environnement du serveur d'application.
Un ou plusieurs modules EJB, contenant chacun un ou plusieurs beans entreprise, peuvent être installés dans un conteneur unique.
- Lancement, validation et annulation des transactions en fonction des besoins.
- Gestion de groupes d'instances de beans enterprise prêts à laisser entrer les demandes et déplacer ces instances entre les groupes inactifs et un état actif, en s'assurant que les conditions d'unité d'exécution sont remplies dans le bean.
- Synchronisation des données dans les variables de l'instance d'un bean entity avec les éléments de données correspondants stockés de manière persistante (élément plus important).
En conservant dynamiquement un ensemble d'instances de beans actives et en synchronisant l'état des beans avec le stockage persistant lorsque les beans sont déplacés de l'état actif, le conteneur permet à une application de gérer bien plus d'instances de beans que ne pourrait contenir autrement la mémoire du serveur d'application. A cet effet, un conteneur d'EJB offre des services identiques pour la mémoire virtuelle dans un système d'exploitation.
WebSphere Application Server facilite sensiblement la gestion des données des bases de données via des beans entity. Les paramètres de configuration Activer à et Charger à des beans EJB entity indiquent de quelle manière et à quel moment doivent être effectués le chargement et la mise en cache des données des lignes de base de données correspondantes d'un bean enterprise. Ces paramètres de configuration permettent de définir les options de mise en cache beans enterprise A, B ou C, comme défini dans les spécifications EJB 1.1. Vous pouvez configurer ces paramètres via les outils d'assemblage. Pour en savoir plus sur l'utilisation des outils d'assemblage, consultez le centre de documentation correspondant.
- Avec l'option A, le serveur d'applications considère que le bean entity
n'est utilisé que dans un seul conteneur. Les clients de ce bean doivent donc
adresser leurs demandes à l'instance résidant dans ce conteneur. Le bean entity bénéficie d'un accès exclusif à la base de données sous-jacente, ce qui signifie qu'il ne peut pas être
cloné ni participer à la gestion de la charge de travail si l'option A est utilisée.Si vous envisagez d'utiliser des scénarios en lecture seule, le produit comporte une autre variété de beans entity option A hautes performances. Cette option de mise en cache est appelée Multithreaded Read-Only. De la même façon que l'option A standard, le conteneur d'EJB continue d'activer le bean juste une fois et le laisse activé jusqu'à ce qu'il ait besoin d'espace dans sa cache d'instances active. Toutefois, le conteneur d'EJB diffère de l'option A standard dans les comportements suivants :
- Il recharge périodiquement l'état du bean à partir du stockage persistant pour répondre à l'appel d'une méthode sur le bean, qui est effectué par l'utilisateur pour collecter les modifications qui ont été apportées au magasin persistant depuis le dernier chargement du bean. Vous pouvez configurer cette fonction en définissant un paramètre Intervalle de rechargement dans le descripteur de déploiement du bean. Pour plus d'informations, voir la rubrique relative au développement de beans entity en lecture seule.
- L'état du bean n'est pas enregistré dans le magasin persistant par le conteneur d'EJB à la fin de la transaction et la méthode ejbStore() du bean n'est pas appelée.
- Le conteneur d'EJB autorise l'appel de méthodes à partir de plusieurs clients (unités d'exécution) sur la même instance de bean. Cette caractéristique diffère du composant EJB standard quant à la structure interne du bean. Vous devez tenir compte de ce point lorsque vous développez votre bean et faire en sorte que la logique figurant dans les méthodes métier du bean respecte le cloisonnement des unités d'exécution.
- Avec l'option B, le bean entity reste actif dans la mémoire cache pendant toute la durée de la transaction mais est rechargé au début de chaque appel de méthode.
- Avec l'option C (sélectionnée par défaut), l'état du bean entity est toujours rechargé à partir de la base de données au début de chaque transaction. Un client peut tenter d'accéder au bean et de démarrer une nouvelle transaction sur n'importe quel conteneur ayant été configuré pour héberger ce bean. Ce procédé est similaire à la fonction de groupage de sessions décrite pour les sessions HTTP, dans la mesure où l'état du bean est conservé dans une base de données partagée, accessible à partir de tout serveur, en fonction des besoins.
L'option A optimise les performances des beans enterprise via la mise en cache des données de la base de données, en-dehors de la portée des transactions. En général, cette option n'est applicable que lorsque le conteneur EJB dispose d'un accès exclusif sur la base de données concernée. Dans les autres cas, l'intégrité des données est compromise. L'option B permet une mise en cache plus énergique des instances d'objets EJB entity, ce qui peut améliorer les performances par rapport à l'option C, mais monopolise aussi davantage de mémoire. L'option C représente la configuration réelle la plus courante pour les beans EJB entity ; elle est d'ailleurs sélectionnée par défaut.
Le paramètre Activer à indique le point d'activation et de mise en cache du bean enterprise. Il administre également les retraits du cache et la passivation. Les valeurs valides sont Once et Transaction. La valeur Once indique que le bean est activé lorsque le serveur y accède pour la première fois, puis passivé (et retiré du cache) lorsque le conteneur le décide (par exemple, lorsque le cache est saturé). La valeur Transaction indique que le bean est activé au début d'une transaction et passivé (et supprimé du cache) à la fin de la transaction. La valeur par défaut est Transaction.
Vous devez utiliser des paramètres occasionnant l'utilisation de l'option B ou C. Si l'option B (accès partagé à la base de données) est sélectionnée, indiquez Activer à = Once et Charger à = Transaction. L'option B peut monopoliser davantage de mémoire, car un plus grand nombre d'objets sont conservés dans le cache. Cela dit, comme chaque transaction crée sa propre copie d'un objet, il peut exister plusieurs copies d'une instance dans la mémoire (une par transaction), ce qui nécessite un accès systématique à la base de données pour chaque transaction. Si un bean enterprise contient un nombre important d'appels à la fonction ejbActivate, l'utilisation de l'option B peut s'avérer bénéfique. En effet, l'objet requis se trouvera déjà dans le cache. Autrement, cette option n'offre pas d'avantages sensibles par rapport à l'option A. Pour l'option (accès partage à la base de données), utilisez Activer à = Transaction et Charger à = Transaction. Grâce au maintien d'un nombre moins important d'objets en cache, cette option peut réduire la quantité de mémoire utilisée. Toutefois, il peut exister plusieurs copies d'une instance dans la mémoire (une par transaction). Un autre avantage de cette option est le nombre réduit de conflits de transactions pour les instances de bean enterprise, qui ne sont pas mises à jour mais sont accessibles par plusieurs éléments à la fois.
Ce produit prend en charge le clonage d'objets home de bean session avec état sur plusieurs serveurs d'applications. Cependant, il ne permet pas de cloner une instance spécifique d'un bean session avec état. Chaque instance d'un bean session avec état particulier n'existe que dans un seul serveur d'applications et, pour être accessible, les demandes qui la concernent doivent être dirigées vers ce serveur et vers celui-ci uniquement. Les informations d'état d'un bean session avec état ne peuvent pas être partagées entre plusieurs membres d'une grappe de serveurs. L'activation de la fonction de reprise en ligne pour bean session avec état et la configuration du conteneur EJB afin d'utiliser la fonction de réplication de mémoire à mémoire ne permet toutefois pas la réplication de bean session avec état sur d'autres serveurs du cluster de sorte que la reprise puisse s'effectuer sur le serveur de secours en cas d'incident sur le serveur principal. Pour plus d'informations sur la reprise après incident par basculement du bean session avec état, voir Reprise en ligne pour les beans session avec état du conteneur EJB.
Par défaut, un conteneur d'EJB fonctionne en mode démarrage rapide. La logique de démarrage du conteneur d'EJB diffère le chargement et le traitement de tous les types d'EJB, sauf les beans gérés par messages (car ils doivent exister avant que des messages ne soient envoyés pour eux), les beans de démarrage (qui doivent être traités au démarrage du serveur) et les types d'EJB dont vous avez indiqué l'initialisation au démarrage du serveur. .
Toute autre initialisation d'EJB est différée jusqu'à la première utilisation du type d'EJB. Si vous utilisez des interfaces locales, la première fois que vous en utilisez une est lorsque vous exécutez une méthode InitialContext.lookup() pour le type. Pour les interfaces éloignées, c'est lorsque vous appelez la première méthode sur un EJB ou sur son interface Home.