Reprise en ligne pour les beans session avec état du conteneur EJB
Vous pouvez utiliser WebSphere Application Server pour construire des applications qui utilisent des beans session avec état qui ne sont pas tributaires de pannes de serveur fortuites. Ce produit utilise les fonctions DRS (Data Replication Service) et WLM (Workload Management) de sorte que vous pouvez activer la reprise en ligne des beans session avec état.
- Vous souhaitez activer la reprise ne ligne pour toutes les applications sauf une. Pour cela, activez cette fonction au niveau du conteneur EJB et remplacez le paramètre au niveau de l'application afin de désactiver la fonction pour l'application voulue.
- Vous souhaitez activer la reprise en ligne pour une seule application installée. Pour cela, désactivez cette fonction au niveau du conteneur EJB et remplacez le paramètre au niveau de l'application afin d'activer la fonction pour l'application voulue.
- Vous souhaitez activer la reprise en ligne pour toutes les applications sauf un module d'une application. Pour cela, activez cette fonction au niveau du conteneur EJB et remplacez le paramètre au niveau de l'application contenant le module pour désactiver la reprise en ligne pour ce seul module.
- Vous souhaitez activer la reprise en ligne pour un seul module EJB installé. Pour cela, désactivez cette fonction au niveau du conteneur EJB et remplacez le paramètre au niveau du module EJB afin d'activer la fonction pour ce seul module EJB.
- Activation ou désactivation de la fonction de reprise en ligne pour bean session avec état à l'aide du panneau Conteneur d'EJB
- Activation ou désactivation de la fonction de reprise en ligne pour bean session avec état à l'aide du panneau Applications d'entreprise
- Activation ou désactivation de la fonction de reprise en ligne pour bean session avec état à l'aide du panneau Modules EJB
Règles d'activation des beans session avec état avec reprise en ligne activée
Vous pouvez indiquer une stratégie d'activation pour les beans session avec état pendant l'assemblage des applications. Il est important de noter que le conteneur EJB prépare une seule fois la reprise en ligne en répliquant les données du bean session avec état à l'aide du service DRS, à savoir lors de la passivation de ce bean. Si vous configurez le bean avec une stratégie à activation unique, qui est la valeur par défaut, le bean n'est pas désactivé assez rapidement pour être utile pour la reprise en ligne avec bean session avec état. Par conséquent, lorsque vous activez la reprise en ligne, le conteneur EJB ignore la stratégie d'activation configurée pour le bean et utilise automatiquement la stratégie d'activation à la limite de la transaction. Cette action assure que le bean est désactivé et que ses données sont répliquées chaque fois qu'il est répertorié dans une transaction exécutée.

Utilisation d'unités de travail gérées par conteneur ou gérées par bean par un bean session avec état lorsque la reprise en ligne est activée
Dans ce cas, les unités de travail sont des transactions et des sessions d'activité. Le produit prend en charge la fonction de reprise en ligne pour bean session avec état à la fois pour les transactions gérées par conteneur et par bean, et pour les sessions d'activité gérées par conteneur et par bean. Toutefois, dans le cas des transactions gérées par conteneur, la reprise en ligne est préparée uniquement en cas d'envoi d'une demande d'appel de méthode de bean enterprise et sans établissement de connexion avec le serveur après cette tentative. Si le serveur connaît une panne après avoir reçu une demande et en avoir accusé réception, la reprise en ligne n'est pas activée. Lorsqu'un incident se produit au cours de l'exécution d'une requête ou d'une unité de travail, le WLM (gestionnaire d'équilibrage de la charge) ne peut pas lancer en toute sécurité une reprise sur un autre serveur si l'application n'exécute pas un code de correction quelconque. Dans ce cas, l'application reçoit une exception CORBA (Common Object Request Broker Architecture) et un code mineur lui indiquant qu'aucune reprise automatique n'est autorisée car l'incident s'est produit lors de l'exécution d'une unité de travail. Vous devez développer l'application de manière à pouvoir vérifier l'exception CORBA et le code mineur, et à rectifier l'incident. Une fois le code de correction exécuté, l'application peut relancer les requêtes et s'il existe un chemin d'accès à un serveur de secours, le WLM achemine la nouvelle requête vers un nouveau serveur primaire pour le bean session avec état.
Pour plus d'informations, reportez-vous à la rubrique Codes mineurs Corba.
Pour plus d'informations, consultez la rubrique Gestion de la charge de travail pour toutes les plateformes à l'exception de z/OS.
Il en va de même pour les unités de travail gérées par bean comme les transactions ou les sessions d'activité. Toutefois, un travail géré par bean introduit une nouvelle possibilité dont il faut tenir compte.
- Une méthode de bean session avec état utilisant une transaction gérée par bean ou une session d'activité appelle la méthode begin sur une transaction UserTransaction qu'elle obtient auprès de l'objet SessionContext. Cette méthode effectue quelques opérations dans l'unité de travail lancée mais ne met pas fin à la transaction ou à la session avant de revenir à l'appelant de la méthode.
- Une fois l'appel de la méthode démarré, le conteneur EJB interrompt le travail qui a été commencé par la méthode. Cette opération est requise par la spécification Enterprise JavaBeans pour la transaction gérée par bean lorsque le bean est un bean session avec état.
- Le client lance plusieurs autres méthodes sur le bean session avec état. A chaque appel de méthode, le conteneur EJB reprend la transaction ou la session d'activité suspendue, diffuse l'appel de méthode puis suspend à nouveau le travail avant de revenir à l'appelant.
- Le client appelle une méthode sur le bean session avec état qui termine la transaction ou la session lancée à l'étape 1.
Ce scénario illustre une unité de travail gérée par bean rémanente. La transaction ou session d'activité attend plusieurs méthodes de bean session avec état. Si une application utilise une transaction ou une session d'activité gérée par bean rémanente et que le serveur connaît une panne une fois l'unité de travail terminée et avant le lancement d'une autre unité de travail rémanente, la reprise en ligne aboutit. Mais, si le serveur connaît une panne avant la fin d'une transaction ou d'une session d'activité rémanente, la reprise en ligne échoue. Par ailleurs, lorsque le processus de reprise en ligne achemine la demande de bean session avec état vers un nouveau serveur, le conteneur EJB détecte que la panne s'est produite au cours d'une transaction ou d'une session d'activité rémanente active. Le conteneur EJB émet alors une exception.
Ce processus indique que la reprise en ligne échoue pour l'unité de travail gérée par conteneur et pour celle gérée par bean si la transaction ou la session d'activité est encore active. La seule différence est qu'une exception se produit pour les unités de travail gérées par bean.
Considérations liées à la conception d'applications
- Pour éviter l'exception décrite dans la section précédente, nous vous conseillons d'écrire votre application de telle sorte que les beans session avec état soient configurés pour utiliser des transactions gérées par conteneur au lieu de transactions gérées par bean-managed.
- Si vous souhaitez exécuter la reprise en ligne et que votre application crée un bean session HTTP ou un bean session avec état qui enregistre une référence dans un autre bean session avec état, l'administrateur doit s'assurer que le bean session HTTP et le bean session avec état sont configurés pour utiliser le même domaine de réplication du service de réplication des données.
- N'utilisez pas de référence locale et une référence distante à un même bean session
avec état.
En principe, une instance de bean session avec état dotée d'une clé primaire donnée ne peut exister que sur un seul serveur à tout moment donné. La reprise en ligne peut provoquer le transfert du bean sur un autre serveur mais le bean ne figure pas simultanément sur plusieurs serveurs. Toutefois, certains scénarios inattendus peuvent produire la même instance de bean (même clé primaire) figurant simultanément sur plusieurs serveurs. Dans ce cas, chaque instance du bean n'est pas consciente de l'existence de l'autre et aucune synchronisation n'a lieu entre les deux instances pour assurer qu'elles contiennent les mêmes données d'état. Votre application reçoit donc des résultats inattendus.
Avertissement : Pour éviter cette situation, n'oubliez pas que si la fonction de reprise en ligne est activée, votre application ne doit jamais recevoir une référence locale (EJBLocalObject) et une référence distante (EJBObject) à la même instance de bean session avec état. - Evitez l'utilisation de méthodes asynchrones distantes sur des beans session avec état.
Lorsqu'une méthode asynchrone est appelée, la demande est mise en file d'attente par le serveur distant et un objet Future est renvoyé au client. Etant donné que la demande de méthode est mise en file d'attente uniquement sur le serveur avec l'instance de bean session avec état, l'objet Future est lié à ce serveur et n'effectue pas de reprise en ligne. Si vous devez utiliser des méthodes asynchrones distantes pour les beans session avec état, développez une application pour détecter lorsqu'un appel de l'objet Future échoue et effectuez un appel synchrone du bean session avec état afin de déterminer si la transaction qui a été démarrée par la méthode asynchrone s'est terminée correctement.
-
Evitez de référencer des temporisateurs EJB non permanents dans une instance de bean session avec état lorsque la reprise en ligne est activée.
Si un bean session avec état comporte un descripteur vers une instance de temporisateur non permanent créé automatiquement ou à l'aide d'un programme, ce descripteur est invalidé après la reprise en ligne du bean session avec état et l'exception javax.ejb.NoSuchObjectLocalException se produit lorsque ce descripteur est utilisé. Si l'application doit faire référence à des temporisateurs non permanents dans des beans session avec état, développez une application qui prenne en compte le descripteur non valide.
Avertissement : Les descripteurs des temporisateurs non permanents, créés automatiquement ou à l'aide d'un programme dans des beans session avec état sont repris en ligne et peuvent être utilisés après une reprise en ligne de bean session avec état.
![[z/OS]](../images/ngzos.gif)
Pour les utilisateurs de z/OS uniquement
- Utilisation de serviteurs multiples
- Configuration du redémarrage et de la reprise sur un système homologue
- Clusters sur lesquels les beans session avec état seront déployés
Du fait que le produit z/OS possède une région de contrôle et une région serviteur alors que WebSphere Application Server, Network Deployment n'en possède pas, il n'existe qu'un scénario de reprise propre à z/OS.
Si vous utilisez la technique basée sur HFS, sous z/OS, poursuivez avec cette technique.
Sur un serveur z/OS non géré, la reprise de beans session avec état entre serviteurs peut être activée. La reprise n'a lieu qu'entre les serviteurs d'un serveur non géré donné. L'activation de la reprise est sans effet si un serveur z/OS non géré n'a qu'un serviteur. Un serveur z/OS non géré sur lequel est activé la fonction de reprise ne peut effectuer de reprise vers un serveur z/OSnon géré. Pour activer la reprise sur un serveur non géré, consultez Activation de la reprise en ligne de serviteurs dans un serveur non géré.