Environnement de cluster et service de temporisateurs

Dans un environnement à un seul serveur, vous savez quelle instance de serveur appelle la méthode timeout du bean sur un bean donné. Dans un environnement à plusieurs serveurs configurés en cluster, le comportement peut varier.

WebSphere Application Server implémente le service de temporisation Enterprise JavaBeans (EJB). Selon les besoins de votre activité, vous pouvez utiliser des temporisateurs persistants ou non persistants. Les temporisateurs persistants conviennent pour un événement périodique qui exige obligatoirement la présence d'un temporisateur au delà du cycle de vie du serveur, c'est-à-dire pour continuer d'exister pendant les arrêts et les redémarrages du serveur. Les temporisateurs persistants qui ont déjà été lancés démarrent automatiquement quand le serveur démarre ; leur stockage exige une instance de base de données. Les temporisateurs non persistants n'utilisent pas de magasin de données et sont annulés quand le serveur d'applications s'arrête ou n'est plus actif. Les temporisateurs non persistants n'existent que sur le serveur où ils ont été créés. Dans un environnement en clusters, si votre application EJB crée automatiquement un temporisateur non persistant et que cette application est répliqué en miroir sur plusieurs serveurs, chaque serveur possède alors son propre temporisateur non persistant qui s'exécute dans l'environnement de ce serveur. Un temporisateur non persistant créé programmatiquement fonctionne uniquement dans le membre de cluster où il a été créé.

Si vous configurez un temporisateur persistant dans un environnement à plusieurs serveurs en cluster, une instance de serveur peut appeler la méthode timeout sur un bean donné de plusieurs manières :

  • Une base de données de temporisateurs distincte par processus serveur ou membre de cluster. Il s'agit de la configuration par défaut. Seule l'instance de serveur ou le membre du cluster ayant créé le temporisateur peut accéder à ce dernier et exécuter la méthode timeout du bean. Si le processus serveur n'est pas disponible, le temporisateur ne s'exécute pas au moment fixé et ce jusqu'au redémarrage du serveur. De plus, si un bean enterprise appelle la méthode getTimers(), les seuls temporisateurs détectés sont ceux qui ont été créés sur l'instance de serveur. Ceci peut générer un comportement inattendu lorsque le bean enterprise tente d'annuler tous les temporisateurs qui lui sont associés. Par exemple, à la suppression du bean enterprise. Cette configuration n'est PAS recommandée pour les systèmes de production.
  • Base de données de temporisateurs commune ou partagée pour le cluster. Les temporisateurs peuvent être créés et ouverts à partir de n'importe quel processus serveur ou membre de cluster. Les temporisateurs créés dans un processus serveur sont détectés par la méthode getTimers() des autres processus serveur du cluster. A la suppression d'un bean entity, tous les temporisateurs, quel que soit l'endroit où ils ont été créés, sont supprimés. Toutefois, tous les temporisateurs sont exécutés sur un unique serveur du cluster, c'est-à-dire que la méthode timeout du bean est exécutée pour tous les temporisateurs sur un même serveur. Le serveur qui exécute les temporisateurs est celui qui obtient un verrouillage sur les tables de la base de données commune. Si le serveur exécutant les temporisateurs vient à ne plus être disponible, un autre serveur ou un membre du cluster prend le relais pour exécuter tous les temporisateurs au moment planifié. Cette configuration est recommandée pour tous les systèmes de production.
  • Eviter les incidents Eviter les incidents: Lorsque vous utilisez le service de temporisateurs EJB dans une application qui accède à la base de données par plusieurs unités d'exécution, le flux de l'application peut introduire des problèmes d'interblocage.gotcha
    Pour éviter ce problème, utilisez l'intention d'accès wsPessimisticUpdate. Avec ce type de tentative d'accès, la méthode de localisation dans votre application exécute une instruction select for update au lieu d'une sélection générique. Cela évite l'interblocage par escalade de verrous lorsque plusieurs unités d'exécution tentent d'escalader leurs verrous pour effectuer une mise à jour.
Pour plus d'informations sur la configuration de la source de données (base de données) à utiliser pour chaque service de temporisateur de processus serveur, voir les informations relatives à l'utilisation du service de temporisateur EJB pour les beans enterprise.
Eviter les incidents Eviter les incidents: Lorsque vous modifiez la source de données du service de temporisateurs de manière qu'elle pointe sur une autre base de données, à son prochain démarrage, le processus serveur tente automatiquement de créer les tables requises dans cette nouvelle base de données.gotcha
Si l'ID utilisateur associé au démarrage du processus serveur n'est pas autorisé à créer des tables de base de données dans la base de données du service de temporisateurs configuré, les tables doivent être créées manuellement.
Eviter les incidents Eviter les incidents: Lorsque vous utilisez le serveur proxy dans le produit, ne définissez pas de planificateur à l'échelle de la cellule si ce planificateur est configuré comme celui à utiliser pour le service de temporisateurs EJB. Faute de quoi, les temporisateurs persistants ne pourront pas fonctionner. Cela peut arriver si le serveur proxy obtient le bail du planificateur. Comme aucune application n'est exécutée dans le serveur proxy, il n'y a pas de code d'application pour traiter les événements de temporisateur envoyés par le planificateur. gotcha
Eviter les incidents Eviter les incidents: Lors de la configuration d'un temporisateur/planificateur EJB, n'oubliez pas que le planificateur par défaut utilise la base de données Apache Derby basée sur un fichier simple pour que vous puissiez rapidement obtenir un environnement fonctionnel. N'UTILISEZ PAS la base de données Derby à des fins de production. De plus, elle n'est pas compatible avec la mise en cluster du planificateur de travaux et du conteneur de travaux par lots.gotcha

Icône indiquant le type de rubrique Rubrique de référence



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=rejb_timerservice_v8
Nom du fichier : rejb_timerservice_v8.html