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.

Pour ne pas activer la reprise en ligne pour chaque bean session avec état installé dans le conteneur EJB (Enterprise JavaBeans), remplacez les paramètres du conteneur EJB au niveau de l'application ou du module EJB. Vous pouvez activer ou désactiver la reprise en ligne à chacun de ces niveaux. Prenons, par exemple, les circonstances suivantes :
  • 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.
Pour savoir comment activer la reprise en ligne pour bean session avec état avec la console d'administration, voir :
  • 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.

Eviter les incidents Eviter les incidents: Lorsque des données sont transmises à DRS pour réplication, le service DRS réplique les données sur les serveurs d'applications N-1 où N correspond au nombre de répliques disponibles. Si le serveur de création et tous les serveurs disposant de copies de sauvegarde sont arrêtés, les données répliquées sont perdues sauf si l'utilisateur DRS réplique à nouveau les données.gotcha

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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

Dans le cas des unités de travail gérées par beans, le processus de reprise en ligne ne peut pas toujours détecter qu'une transaction ou une session d'activité gérée par bean lancée par une méthode de bean session avec état n'a pas été exécutée correctement. Il est donc possible qu'une reprise en ligne soit effectuée sur un nouveau serveur bien que l'unité de travail se soit interrompue au milieu d'une transaction ou d'une session. L'unité de travail étant implicitement annulée, le WLM agit comme s'il était possible d'opérer en toute sécurité une reprise sur un autre serveur, alors qu'un code de correction est peut-être nécessaire. Lorsque cette erreur survient, le conteneur EJB la détecte sur le nouveau serveur et initie une exception. Cette exception se produit dans le scénario suivant :
  1. 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.
  2. 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.
  3. 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.
  4. 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

Tenez compte des informations suivantes lors de la conception d'applications utilisant le processus de reprise en ligne des beans session avec état :
  • 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]

Pour les utilisateurs de z/OS uniquement

La reprise de bean session avec état sur WebSphere Application Server, Network Deployment for z/OS diffère légèrement de celle qui est mise en oeuvre sur le produit WebSphere Application Server, Network Deployment. Outre la solution de reprise présentée ici, les utilisateurs z/OS peuvent également activer la reprise parmi les serviteurs d'un serveur non géré. Pour plus d'informations, voir les rubriques :
  • 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é.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_sfsbf
Nom du fichier : cejb_sfsbf.html